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

[Aaron Tomlin]

On Thu, May 21, 2026 at 07:29:48PM -0400, Aaron Tomlin wrote:
> 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.

Hi everyone,

I am writing to politely follow up and request feedback on the v15
iteration of the 'isolcpus=io_queue' patch series.

As noted in the cover letter, this version introduces a major architectural
simplification compared to the older v12 design. Specifically, the complex
"top-down" mask plumbing and struct irq_affinity modifications have been
completely abandoned.

Instead, this iteration relies on a much cleaner, centralized approach
using direct isolation querying via housekeeping_cpumask(HK_TYPE_IO_QUEUE)
within the genirq/affinity subsystem. This pivot successfully decouples the
core infrastructure changes from driver-specific implementations, which
should significantly reduce the maintenance burden.

I would greatly appreciate it if anyone has the bandwidth to review this
new approach. Please let me know your thoughts or if there are any further
refinements needed.

Thank you for your time and guidance.

Kind regards,
-- 
Aaron Tomlin

Attachment: signature.asc
Description: PGP signature