Re: [PATCH v10 13/13] docs: add io_queue flag to isolcpus

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

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