Re: [PATCH v10 13/13] docs: add io_queue flag to isolcpus

[Aaron Tomlin]

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

Attachment: signature.asc
Description: PGP signature