Re: [PATCH v15 0/8] blk: honor isolcpus configuration

[Aaron Tomlin]

On Fri, Jul 10, 2026 at 05:21:59PM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-05-21 19:29:48 [-0400], Aaron Tomlin wrote:
> > Hi,
> Hi,
> 
> > I have decided to drive this series forward on behalf of Daniel Wagner, the
> > original author. The series has been rebased on v7.1-rc4-100-g8bc67e4db64a.
> > 
> > This series introduces a new CPU isolation feature, "isolcpus=io_queue",
> > designed to protect isolated cores from the disruptive hardware interrupts
> > generated by high-performance multi-queue devices.
> > 
> > When enabled, it fundamentally alters how the generic IRQ subsystem and the
> > block layer (blk-mq) map hardware queues:
> > 
> >     1.  Restricted IRQ Affinity: Managed hardware interrupts are strictly
> >         confined to online housekeeping CPUs.
> > 
> >     2.  Transparent I/O Submission: Applications running on isolated CPUs
> >         can still seamlessly submit I/O requests; however, the resulting
> >         hardware completion interrupts are safely routed to a designated
> >         housekeeping CPU.
> > 
> >     3.  Topology-Aware Queue Allocation: The generic CPU-to-hardware-queue
> >         mapping logic is extended to distribute hardware contexts evenly
> >         among the available housekeeping CPUs, preventing MSI-X vector
> >         exhaustion while maintaining optimal cache locality where possible.
> > 
> > To prevent I/O stalls, the block layer is additionally hardened to reject
> > hot-plug requests that attempt to offline a housekeeping CPU if it is the
> > last remaining CPU actively serving an online isolated core.
> > 
> > The complex "top-down" mask plumbing introduced in v12, which modified
> > struct irq_affinity and expanded block layer APIs, has been abandoned. It
> > is replaced by a centralised approach: direct isolation querying via
> > housekeeping_cpumask(HK_TYPE_IO_QUEUE) within the genirq/affinity
> > subsystem. This architectural simplification successfully decouples core
> > changes from driver-specific implementations.
> > 
> > Please let me know your thoughts.
> 
> I think I asked this or wanted to: Why not mage managed_irqs consider
> this? Or is there a case where those two options want a different thing?
> With managed_irqs you specify a mask but this is may not be respected if
> you have more IRQs than you specify. This means the IRQs will still be
> routed to isolated CPUs.
> This option is intended to avoid any interrupts on isolated CPUs.
> Wouldn't it be possible to allow managed_irqs to restrict a device to
> two CPUs only and use two queues only instead of the available 64 or do
> I miss something fundamental why those two need to be separate?

Hi Sebastian,

Please see my response here [1].

[1]: https://lore.kernel.org/lkml/xjcwes5caiwh3eumqfuvankokb7wzzokleqfkfmkh5sgl333sg@nwlgqvj4vdet/

Kind regards,
-- 
Aaron Tomlin