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

[Ming Lei <ming.lei@redhat.com>]

On Sun, Apr 05, 2026 at 09:15:36PM -0400, Aaron Tomlin wrote:
> 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.

I don't think there is such breaking isolation thing. For iopoll, if
applications won't submit polled IO on isolated CPUs, everything is just
fine. If they do it, IO may be reaped from isolated CPUs, that is just their
choice, anything is wrong?

> 
> 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.

I am not sure if the above words is helpful from administrator viewpoint about
the two kernel parameters.

IMO, only two differences from this viewpoint:

1) `io_queue` may reduce nr_hw_queues

2) when application submits IO from isolated CPUs, `io_queue` can complete
IO from housekeeping CPUs.

> 
> > > +
> > > +			  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?

I meant this point can't be found in the patches.


Thanks, 
Ming