From: Ming Lei <ming.lei@redhat.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, Tejun Heo <tj@kernel.org>,
linux-kernel@vger.kernel.org, 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>,
ming.lei@redhat.com
Subject: Re: [PATCH V2] blk-mq: don't schedule block kworker on isolated CPUs
Date: Wed, 25 Oct 2023 09:05:03 +0800 [thread overview]
Message-ID: <ZThpvzrLGQFqpsYb@fedora> (raw)
In-Reply-To: <293c16d2-f556-4d42-ab06-2e0acf1cc601@acm.org>
On Tue, Oct 24, 2023 at 09:53:49AM -0700, Bart Van Assche wrote:
>
> On 10/13/23 05:47, Ming Lei wrote:
> > @@ -3926,6 +3941,15 @@ static void blk_mq_map_swqueue(struct request_queue *q)
> > */
> > sbitmap_resize(&hctx->ctx_map, hctx->nr_ctx);
> > + /*
> > + * rule out isolated CPUs from hctx->cpumask for avoiding to
> > + * run wq worker on isolated CPU
> > + */
> > + for_each_cpu(cpu, hctx->cpumask) {
> > + if (cpu_is_isolated(cpu))
> > + cpumask_clear_cpu(cpu, hctx->cpumask);
> > + }
>
> What will happen if this code makes hctx->cpumask empty? Code like
> blk_mq_first_mapped_cpu() and blk_mq_hctx_next_cpu() assumes that
> hctx->cpumask is not empty. There may be other code that assumes that
> hctx->cpumask is not empty.
hctx->cpumask is only used for selecting next cpu to schedule run
queue now, so it is fine for hctx->cpumask to be empty.
But the patch has one hole, following the delta fix:
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 0917f8eabab9..1d9a7ded27af 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2159,7 +2159,7 @@ 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)
+ if (hctx->queue->nr_hw_queues == 1 || next_cpu >= nr_cpu_ids)
return WORK_CPU_UNBOUND;
if (--hctx->next_cpu_batch <= 0) {
Thanks,
Ming
prev parent reply other threads:[~2023-10-25 1:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-13 12:47 [PATCH V2] blk-mq: don't schedule block kworker on isolated CPUs Ming Lei
2023-10-18 0:52 ` Joe Mario
2023-10-23 23:45 ` Ming Lei
2023-10-24 16:53 ` Bart Van Assche
2023-10-25 1:05 ` 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=ZThpvzrLGQFqpsYb@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=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.