All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Andrew Theurer <atheurer@redhat.com>,
	Joe Mario <jmario@redhat.com>, Sebastian Jug <sejug@redhat.com>,
	Frederic Weisbecker <frederic@kernel.org>,
	Bart Van Assche <bvanassche@acm.org>, Tejun Heo <tj@kernel.org>,
	ming.lei@redhat.com
Subject: Re: [PATCH V4] blk-mq: don't schedule block kworker on isolated CPUs
Date: Fri, 22 Mar 2024 09:10:47 +0800	[thread overview]
Message-ID: <Zfzal65zM3u+1qXc@fedora> (raw)
In-Reply-To: <05c44354-1c48-409e-827f-910d1e3c2db9@kernel.dk>

On Thu, Mar 21, 2024 at 11:07:52AM -0600, Jens Axboe wrote:
> On 3/19/24 8:34 PM, Ming Lei wrote:
> > Kernel parameter of `isolcpus=` or 'nohz_full=' are used to isolate CPUs
> > for specific task, and it isn't expected to let block IO disturb these CPUs.
> > blk-mq kworker shouldn't be scheduled on isolated CPUs. Also if isolated
> > CPUs is run for blk-mq kworker, long block IO latency can be caused.
> > 
> > Kernel workqueue only respects CPU isolation for WQ_UNBOUND, for bound
> > WQ, the responsibility is on user because CPU is specified as WQ API
> > parameter, such as mod_delayed_work_on(cpu), queue_delayed_work_on(cpu)
> > and queue_work_on(cpu).
> > 
> > So not run blk-mq kworker on isolated CPUs by removing isolated CPUs
> > from hctx->cpumask. Meantime use queue map to check if all CPUs in this
> > hw queue are offline instead of hctx->cpumask, this way can avoid any
> > cost in fast IO code path, and is safe since hctx->cpumask are only
> > used in the two cases.
> 
> In general, I think the fix is fine. Only thing that's a bit odd is:

Thanks for the review!

> 
> > diff --git a/block/blk-mq.c b/block/blk-mq.c
> > index 555ada922cf0..187fbfacb397 100644
> > --- a/block/blk-mq.c
> > +++ b/block/blk-mq.c
> > @@ -28,6 +28,7 @@
> >  #include <linux/prefetch.h>
> >  #include <linux/blk-crypto.h>
> >  #include <linux/part_stat.h>
> > +#include <linux/sched/isolation.h>
> >  
> >  #include <trace/events/block.h>
> >  
> > @@ -2179,7 +2180,11 @@ static int blk_mq_hctx_next_cpu(struct blk_mq_hw_ctx *hctx)
> >  	bool tried = false;
> >  	int next_cpu = hctx->next_cpu;
> >  
> > -	if (hctx->queue->nr_hw_queues == 1)
> > +	/*
> > +	 * Switch to unbound work if all CPUs in this hw queue fall
> > +	 * into isolated CPUs
> > +	 */
> > +	if (hctx->queue->nr_hw_queues == 1 || next_cpu >= nr_cpu_ids)
> >  		return WORK_CPU_UNBOUND;
> 
> This relies on find_next_foo() returning >= nr_cpu_ids if the set is
> empty, which is a lower level implementation detail that someone reading
> this code may not know.

Indeed, looks it is more readable to add one helper:

static bool blk_mq_hctx_empty_cpumask(struct blk_mq_hw_ctx *hctx)
{
	return hctx->next_cpu >= nr_cpu_ids;
}

> 
> >  	if (--hctx->next_cpu_batch <= 0) {
> > @@ -3488,14 +3493,30 @@ static bool blk_mq_hctx_has_requests(struct blk_mq_hw_ctx *hctx)
> >  	return data.has_rq;
> >  }
> >  
> > -static inline bool blk_mq_last_cpu_in_hctx(unsigned int cpu,
> > -		struct blk_mq_hw_ctx *hctx)
> > +static bool blk_mq_hctx_has_online_cpu(struct blk_mq_hw_ctx *hctx,
> > +		unsigned int this_cpu)
> >  {
> > -	if (cpumask_first_and(hctx->cpumask, cpu_online_mask) != cpu)
> > -		return false;
> > -	if (cpumask_next_and(cpu, hctx->cpumask, cpu_online_mask) < nr_cpu_ids)
> > -		return false;
> > -	return true;
> > +	enum hctx_type type = hctx->type;
> > +	int cpu;
> > +
> > +	/*
> > +	 * hctx->cpumask has rule out isolated CPUs, but userspace still
>                             ^^
> 
> has to
> 
> > +	 * might submit IOs on these isolated CPUs, so use queue map to
> 							  ^^
> 
> use the queue map

OK, will fix them in V5.


thanks,
Ming


      reply	other threads:[~2024-03-22  1:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-20  2:34 [PATCH V4] blk-mq: don't schedule block kworker on isolated CPUs Ming Lei
2024-03-21 12:49 ` Ming Lei
2024-03-21 17:07 ` Jens Axboe
2024-03-22  1:10   ` Ming Lei [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zfzal65zM3u+1qXc@fedora \
    --to=ming.lei@redhat.com \
    --cc=atheurer@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=frederic@kernel.org \
    --cc=jmario@redhat.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sejug@redhat.com \
    --cc=tim.c.chen@linux.intel.com \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.