On Wed, Apr 15, 2026 at 4:35 PM Sebastian Andrzej Siewior <[email protected]> wrote: > > 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?
Yes, that is why I call it one optimization, however it does introduce cost of CPU offline failure, please see patch 11. Thanks, Ming Lei
