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 <[email protected]> > > > > 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/[email protected]/ > > 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
signature.asc
Description: PGP signature
