Messages in this thread | | | Date | Mon, 25 Mar 2019 17:50:13 +0800 | From | Ming Lei <> | Subject | Re: Virtio-scsi multiqueue irq affinity |
| |
On Mon, Mar 25, 2019 at 09:53:28AM +0100, Thomas Gleixner wrote: > Ming, > > On Mon, 25 Mar 2019, Ming Lei wrote: > > On Mon, Mar 25, 2019 at 01:02:13PM +0800, Peter Xu wrote: > > > One thing I can think of is the real-time scenario where "isolcpus=" > > > is provided, then logically we should not allow any isolated CPUs to > > > be bound to any of the multi-queue IRQs. Though Ming Lei and I had a > > > > So far, this behaviour is made by user-space. > > > > >From my understanding, IRQ subsystem doesn't handle "isolcpus=", even > > though the Kconfig help doesn't mention irq affinity affect: > > > > Make sure that CPUs running critical tasks are not disturbed by > > any source of "noise" such as unbound workqueues, timers, kthreads... > > Unbound jobs get offloaded to housekeeping CPUs. This is driven by > > the "isolcpus=" boot parameter. > > isolcpus has no effect on the interupts. That's what 'irqaffinity=' is for.
Indeed.
irq_default_affinity is built from 'irqaffinity=', however, we don't consider irq_default_affinity for managed IRQ affinity.
Looks Peter wants to exclude some CPUs from the spread on managed IRQ.
Thanks, Ming
| |