Re: [PATCH v9 09/13] isolation: Introduce io_queue isolcpus type

[Aaron Tomlin]

On Wed, Apr 01, 2026 at 02:49:47PM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-03-30 18:10:43 [-0400], Aaron Tomlin wrote:
> > From: Daniel Wagner <wagi@xxxxxxxxxx>
> > 
> > Multiqueue drivers spread I/O queues across all CPUs for optimal
> > performance. However, these drivers are not aware of CPU isolation
> > requirements and will distribute queues without considering the isolcpus
> > configuration.
> > 
> > Introduce a new isolcpus mask that allows users to define which CPUs
> > should have I/O queues assigned. This is similar to managed_irq, but
> > intended for drivers that do not use the managed IRQ infrastructure
> 
> I set down and documented the behaviour of managed_irq at
> 	https://lore.kernel.org/all/20260401110232.ET5RxZfl@xxxxxxxxxxxxx/
> 
> Could we please clarify whether we want to keep it and this
> additionally or if managed_irq could be used instead. This adds another
> bit. If networking folks jump in on managed_irqs, would they need to
> duplicate this with their net sub flag?

Hi Sebastian,

Thank you for taking the time to document the "managed_irq" behaviour; it
is immensely helpful. You raise a highly pertinent point regarding the
potential proliferation of "isolcpus=" flags. It is certainly a situation
that must be managed carefully to prevent every subsystem from demanding
its own bit.

To clarify the reasoning behind introducing "io_queue" rather than strictly
relying on managed_irq:

The managed_irq flag belongs firmly to the interrupt subsystem. It dictates
whether a CPU is eligible to receive hardware interrupts whose affinity is
managed by the kernel. Whilst many modern block drivers use managed IRQs,
the block layer multi-queue mapping encompasses far more than just
interrupt routing. It maps logical queues to CPUs to handle I/O submission,
software queues, and crucially, poll queues, which do not utilise
interrupts at all. Furthermore, there are specific drivers that do not use
the managed IRQ infrastructure but still rely on the block layer for queue
distribution.

If managed_irq were solely relied upon, the IRQ subsystem would
successfully keep hardware interrupts off the isolated CPUs, but the block
layer would still blindly map polling queues or non-managed queues to those
same isolated CPUs. This would force isolated CPUs to process I/O
submissions or handle polling tasks, thereby breaking the strict isolation.

Regarding the point about the networking subsystem, it is a very valid
comparison. If the networking layer wishes to respect isolcpus in the
future, adding a net flag would indeed exacerbate the bit proliferation.

For the present time, retaining io_queue seems the most prudent approach to
ensure that block queue mapping remains semantically distinct from
interrupt delivery. This provides an immediate and clean architectural
boundary. However, if the consensus amongst the maintainers suggests that
this is too granular, alternative approaches could certainly be considered
for the future. For instance, a broader, more generic flag could be
introduced to encompass both block and future networking queue mappings.
Alternatively, if semantic conflation is deemed acceptable, the existing
managed_irq housekeeping mask could simply be overloaded within the block
layer to restrict all queue mappings.

Keeping the current separation appears to be the cleanest solution for this
series, but your thoughts, and those of the wider community, on potentially
migrating to a consolidated generic flag in the future would be very much
welcomed.


Kind regards,
-- 
Aaron Tomlin

Attachment: signature.asc
Description: PGP signature