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

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

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?

Sebastian