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

[Aaron Tomlin]

On Thu, Apr 09, 2026 at 11:00:09PM +0800, Ming Lei wrote:
> How can the isolated core be scheduled for running polling task?
> 
> Who triggered it?
> 
> > loop waiting for the hardware completion. This would completely monopolise
> > the core and destroy any real time isolation guarantees without the user
> > space application ever having requested it.
> 
> No.
> 
> IOPOLL queue doesn't have interrupt, and the ->poll() is only run from
> the submission context.  So if you don't submitted polled IO on isolated
> CPU cores, everything is just fine.  This is simpler than irq IO actually.

Yes, you are entirely correct. The ->iopoll() is indeed executed strictly
within the submission context. In the example below, the file operations
iopoll callback is iocb_bio_iopoll():

      // file->f_op->iopoll(&rw->kiocb, iob, poll_flags)
      iocb_bio_iopoll(&rw->kiocb, iob, poll_flags)
      {
        struct bio *bio

        bio = READ_ONCE(kiocb->private)
        if (bio)
          bio_poll(bio, iob, flags)
            if (queue_is_mq(q))
              blk_mq_poll(q, cookie, iob, flags)
              {
                if (!blk_mq_can_poll(q))
                  return 0

                blk_hctx_poll(q, q->queue_hw_ctx[cookie], iob, flags)
                {
                    int ret

                    do {
                        ret = q->mq_ops->poll(hctx, iob)
                        if (ret > 0)
                            return ret
                        if (task_sigpending(current))
                            return 1
                        if (ret < 0 || (flags & BLK_POLL_ONESHOT))
                            break
                        cpu_relax()
                    } while (!need_resched())

                    return 0
                }
              }

If an application on an isolated CPU does not explicitly submit a polled
I/O request, it will not poll. Thank you for correcting me on this.

> Can you share one example in which managed irq can't address?

Without io_queue, the block layer maps isolated CPUs to these queues, and
the device will fire unmanaged interrupts that can freely land on isolated
CPUs, thereby breaking isolation. By applying the constraint via io_queue
at the block layer, we restrict the hardware queue count and map the
isolated CPUs to the housekeeping queues, ensuring isolation is maintained
regardless of whether the driver uses managed interrupts.

Does the above help?

> > >
> > > 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.
> >
> > Acknowledged.
> 
> Are there other major differences besides the two mentioned above?

I believe the above is sufficient. Please let me know your thoughts.


Kind regards,
-- 
Aaron Tomlin

Attachment: signature.asc
Description: PGP signature