From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: linux-block@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>,
Thomas Gleixner <tglx@linutronix.de>,
Paolo Bonzini <pbonzini@redhat.com>,
Ming Lei <ming.lei@redhat.com>
Subject: [PATCH] blk-mq: Remove get_cpu() in __blk_mq_delay_run_hw_queue().
Date: Tue, 15 Feb 2022 10:11:59 +0100 [thread overview]
Message-ID: <YgtuX9dDpXe8Xbs+@linutronix.de> (raw)
The callchain:
__blk_mq_delay_run_hw_queue(x, false, x)
cpu = get_cpu();
cpumask_test_cpu(cpu, hctx->cpumask);
__blk_mq_run_hw_queue(hctx);
blk_mq_run_dispatch_ops();
__blk_mq_run_dispatch_ops(x, true, x);
might_sleep_if(true);
will trigger the might_sleep warning since get_cpu() disables
preemption. Based on my understanding, __blk_mq_run_hw_queue() should
run on the requested CPU for the benefit of cache locality. The system
won't crash if it runs on another CPU but the performance will be
probably less than optimal.
If the current CPU matches the requested cpumask then it may remain and
fulfill the requirement. If the scheduler moves the task to another CPU
then it will run on the wrong CPU but no harm is done in terms of
correctness.
Remove get_cpu() from __blk_mq_delay_run_hw_queue().
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
I have nothing to trigger that path, this is based on review. I see the
callchain but with blk_queue_has_srcu == 0.
The calls I see are from per-CPU threads and from unbound CPU threads.
If the correct CPU is important then migrate_disable() could be used
(slightly higher overhead than preempt_disable() but preemptible) or
unconditionally pass to kblockd_mod_delayed_work_on() (higher overhead
than migrate_disable() but will be done anyway if the current CPU is
wrong).
block/blk-mq.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 1adfe4824ef5e..90217f1b09add 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2040,14 +2040,10 @@ static void __blk_mq_delay_run_hw_queue(struct blk_mq_hw_ctx *hctx, bool async,
return;
if (!async && !(hctx->flags & BLK_MQ_F_BLOCKING)) {
- int cpu = get_cpu();
- if (cpumask_test_cpu(cpu, hctx->cpumask)) {
+ if (cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask)) {
__blk_mq_run_hw_queue(hctx);
- put_cpu();
return;
}
-
- put_cpu();
}
kblockd_mod_delayed_work_on(blk_mq_hctx_next_cpu(hctx), &hctx->run_work,
--
2.34.1
next reply other threads:[~2022-02-15 9:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-15 9:11 Sebastian Andrzej Siewior [this message]
2022-02-15 9:23 ` [PATCH] blk-mq: Remove get_cpu() in __blk_mq_delay_run_hw_queue() Ming Lei
2022-02-15 9:31 ` Sebastian Andrzej Siewior
2022-02-15 11:58 ` Ming Lei
2022-02-15 12:11 ` Sebastian Andrzej Siewior
2022-02-15 12:22 ` Ming Lei
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=YgtuX9dDpXe8Xbs+@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox