On 2026-04-13 23:11:15 [+0800], Ming Lei wrote: > > > What matters is that IO won't interrupt isolated CPU. > > > > The isolcpus=managed_irq acts as a "best effort" avoidance algorithm rather > > than a strict, unbreakable constraint. This is indicated in the proposed > > changes to Documentation/core-api/irq/managed_irq.rst [1]. > > Yes, it is "best effort", but isolated cpu is only take as effective CPU > for the hw queue's irq iff all others are offline. Which is just fine for > typical > use cases, in which IO isn't submitted from isolated CPU.
Couldn't we tackle this by limiting the number of managed interrupts the device asks for and then limiting the CPUs it could be bound to? So if have house keeping CPUs 0/1 and isolated 2-63 then managed_irq= is futile since it use 64 interrupts and map each to one CPU. Even if the device supports less it would map them evenly across available CPUs. If the user wishes to initiate I/O from all CPUs but not be bother by interrupts we could limit the device to ask for 2 interrupts instead of 64 (with the consequence of more queue sharing) and then limit those two interrupts to CPU 0 and 1 instead to CPU 0-31 and 32-63 like it would be now the case. Wouldn't that be what the io_queue flag tries to do? > Thanks, > Ming Sebastian
