Re: [PATCH v3] blk-mq: dispatch kworker to housekeeping CPU when hctx cpumask is empty

[Aaron Tomlin]

On Tue, Oct 20, 2026 at 09:23:10AM -0600, Jens Axboe wrote:
> On 10/15/26 11:22 PM, Aaron Tomlin wrote:
> > diff --git a/block/blk-mq.c b/block/blk-mq.c
> > index 025a799f35b9..1a113679f15b 100644
> > --- a/block/blk-mq.c
> > +++ b/block/blk-mq.c
> > @@ -2241,6 +2241,21 @@ static bool blk_mq_hctx_empty_cpumask(struct blk_mq_hw_ctx *hctx)
> >          return hctx->next_cpu >= nr_cpu_ids;
> >  }
> >  
> > +static inline int blk_mq_hctx_unbound_cpu(void)
> > +{
> > +	if (cpu_is_isolated(raw_smp_processor_id())) {
> > +		int cpu;
> > +
> > +		guard(rcu)();
> > +
> > +		cpu = cpumask_any_and_distribute(housekeeping_cpumask(HK_TYPE_DOMAIN),
> > +						 cpu_online_mask);
> > +		if (cpu < nr_cpu_ids)
> > +			return cpu;
> > +	}
> > +	return WORK_CPU_UNBOUND;
> > +}
> 
> Not opposed to this, but let's please think about making the
> common case the fast path. CPU isolation is not the common
> path. That might mean annotating the hctx itself.
> 

Hi Jens,

Agreed on keeping the fast path penalty-free.

For multi-queue devices, blk_mq_hctx_empty_cpumask(hctx) already serves as
that annotation (via hctx->next_cpu >= nr_cpu_ids) since isolated CPUs are
stripped during mapping, so normal multi-queue devices never hit that path.

The main concern is single-queue devices (nr_hw_queues == 1), where the
hctx is shared between housekeeping and isolated cores. To avoid calling
cpu_is_isolated() on every deferred dispatch in the common case, we can
split the check and gate it behind a static key:
static_branch_unlikely(&housekeeping_overridden)

I will prepare a v4.

Kind regards,
-- 
Aaron Tomlin