On Fri, Apr 03, 2026 at 10:30:26AM +0800, Ming Lei wrote: > On Wed, Apr 01, 2026 at 06:23:12PM -0400, Aaron Tomlin wrote: > > All these can be supported by `managed_irq` already, please document the thing > which `io_queue` solves, and `managed_irq` can't cover, so user can know > how to choose between the two command lines. > > `Restrict the placement of queues to housekeeping CPUs only` looks totally > stale, please see patch 10, in which isolated CPUs are spread too.
Dear Ming, Thank you for your careful review of the documentation and for raising these excellent points. I completely agree that the administrator guide must be as unambiguous as possible. Regarding your first point on the distinction between managed_irq and io_queue, you are entirely correct that the documentation must explicitly guide the user in their choice. I shall revise the text to clarify that where managed_irq solely restricts the affinity of hardware interrupts at the interrupt controller level, io_queue governs the block layer multi-queue mapping algorithm itself. I will add a clear explanation that io_queue is required for users who utilise polling queues, which do not rely on interrupts, or specific drivers that do not use the managed interrupt infrastructure. Without io_queue, the block layer would still assign these polling duties to isolated CPUs, thereby breaking the isolation. Every logical CPU, including the isolated ones, must logically map to a hardware context in order to submit input and output requests, saying they are completely restricted is indeed stale and technically inaccurate. The isolation mechanism actually ensures that the hardware contexts themselves are serviced by the housekeeping CPUs, while the isolated CPUs are simply mapped onto these housekeeping queues for submission purposes. I will rewrite this paragraph to accurately reflect this topology, ensuring it aligns perfectly with the behaviour introduced in patch 10. > > + > > + The io_queue configuration takes precedence > > + over managed_irq. When io_queue is used, > > + managed_irq placement constrains have no > > + effect. > > + > > + Note: Offlining housekeeping CPUS which serve > > + isolated CPUs will be rejected. Isolated CPUs > > + need to be offlined before offlining the > > + housekeeping CPUs. > > + > > + Note: When an isolated CPU issues an I/O request, > > + it is forwarded to a housekeeping CPU. This will > > + trigger a software interrupt on the completion > > + path. > > `io_queue` doesn't touch io completion code path, which is more > implementation details, so not sure if the above Note is needed. Possibly the original author intended to suggest that the software interrupt is sent to the isolated CPU? To achieve absolute zero disturbance, an isolated CPU must either entirely abstain from submitting standard I/O, or it must exclusively utilise polling queues, where the CPU actively checks for completions and entirely bypasses the interrupt and softirq mechanisms. Kind regards, -- Aaron Tomlin
signature.asc
Description: PGP signature
