From: Damien Le Moal <dlemoal@kernel.org>
To: Yu Kuai <yukuai1@huaweicloud.com>,
hare@suse.de, tj@kernel.org, josef@toxicpanda.com,
axboe@kernel.dk, yukuai3@huawei.com
Cc: cgroups@vger.kernel.org, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, yi.zhang@huawei.com,
yangerkun@huawei.com, johnny.chenyi@huawei.com
Subject: Re: [PATCH 4/6] elevator: factor elevator lock out of dispatch_request method
Date: Wed, 23 Jul 2025 10:59:18 +0900 [thread overview]
Message-ID: <08c989bd-20d8-476c-af99-c9eb8065349d@kernel.org> (raw)
In-Reply-To: <20250722072431.610354-5-yukuai1@huaweicloud.com>
On 7/22/25 4:24 PM, Yu Kuai wrote:
> From: Yu Kuai <yukuai3@huawei.com>
>
> Currently, both mq-deadline and bfq have global spin lock that will be
> grabbed inside elevator methods like dispatch_request, insert_requests,
> and bio_merge. And the global lock is the main reason mq-deadline and
> bfq can't scale very well.
>
> For dispatch_request method, current behavior is dispatching one request at
s/current/the current
> a time. In the case of multiple dispatching contexts, this behavior will
> cause huge lock contention and messing up the requests dispatching
s/messing up/change
> order. And folloiwng patches will support requests batch dispatching to
s/folloiwng/following
> fix thoses problems.
>
> While dispatching request, blk_mq_get_disatpch_budget() and
> blk_mq_get_driver_tag() must be called, and they are not ready to be
> called inside elevator methods, hence introduce a new method like
> dispatch_requests is not possible.
>
> In conclusion, this patch factor the global lock out of dispatch_request
> method, and following patches will support request batch dispatch by
> calling the methods multiple time while holding the lock.
You are creating a bisect problem here. This patch breaks the schedulers
dispatch atomicity without the changes to the calls to the elevator methods in
the block layer.
So maybe reorganize these patches to have the block layer changes first, and
move patch 1 and 3 after these to switch mq-deadline and bfq to using the
higher level lock correctly, removing the locking from bfq_dispatch_request()
and dd_dispatch_request().
>
> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> ---
> block/bfq-iosched.c | 3 ---
> block/blk-mq-sched.c | 6 ++++++
> block/mq-deadline.c | 5 +----
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
> index 11b81b11242c..9f8a256e43f2 100644
> --- a/block/bfq-iosched.c
> +++ b/block/bfq-iosched.c
> @@ -5307,8 +5307,6 @@ static struct request *bfq_dispatch_request(struct blk_mq_hw_ctx *hctx)
> struct bfq_queue *in_serv_queue;
> bool waiting_rq, idle_timer_disabled = false;
>
> - spin_lock_irq(bfqd->lock);
> -
> in_serv_queue = bfqd->in_service_queue;
> waiting_rq = in_serv_queue && bfq_bfqq_wait_request(in_serv_queue);
>
> @@ -5318,7 +5316,6 @@ static struct request *bfq_dispatch_request(struct blk_mq_hw_ctx *hctx)
> waiting_rq && !bfq_bfqq_wait_request(in_serv_queue);
> }
>
> - spin_unlock_irq(bfqd->lock);
> bfq_update_dispatch_stats(hctx->queue, rq,
> idle_timer_disabled ? in_serv_queue : NULL,
> idle_timer_disabled);
> diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
> index 55a0fd105147..82c4f4eef9ed 100644
> --- a/block/blk-mq-sched.c
> +++ b/block/blk-mq-sched.c
> @@ -98,6 +98,7 @@ static int __blk_mq_do_dispatch_sched(struct blk_mq_hw_ctx *hctx)
> max_dispatch = hctx->queue->nr_requests;
>
> do {
> + bool sq_sched = blk_queue_sq_sched(q);
> struct request *rq;
> int budget_token;
>
> @@ -113,7 +114,12 @@ static int __blk_mq_do_dispatch_sched(struct blk_mq_hw_ctx *hctx)
> if (budget_token < 0)
> break;
>
> + if (sq_sched)
> + spin_lock_irq(&e->lock);
> rq = e->type->ops.dispatch_request(hctx);
> + if (sq_sched)
> + spin_unlock_irq(&e->lock);
> +
> if (!rq) {
> blk_mq_put_dispatch_budget(q, budget_token);
> /*
> diff --git a/block/mq-deadline.c b/block/mq-deadline.c
> index e31da6de7764..a008e41bc861 100644
> --- a/block/mq-deadline.c
> +++ b/block/mq-deadline.c
> @@ -466,10 +466,9 @@ static struct request *dd_dispatch_request(struct blk_mq_hw_ctx *hctx)
> struct request *rq;
> enum dd_prio prio;
>
> - spin_lock(dd->lock);
> rq = dd_dispatch_prio_aged_requests(dd, now);
> if (rq)
> - goto unlock;
> + return rq;
>
> /*
> * Next, dispatch requests in priority order. Ignore lower priority
> @@ -481,8 +480,6 @@ static struct request *dd_dispatch_request(struct blk_mq_hw_ctx *hctx)
> break;
> }
>
> -unlock:
> - spin_unlock(dd->lock);
> return rq;
> }
>
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2025-07-23 2:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-22 7:24 [PATCH 0/6] blk-mq-sched: support request batch dispatching for sq elevator Yu Kuai
2025-07-22 7:24 ` [PATCH 1/6] mq-deadline: switch to use high layer elevator lock Yu Kuai
2025-07-23 1:46 ` Damien Le Moal
2025-07-23 2:07 ` Yu Kuai
2025-07-23 2:38 ` Damien Le Moal
2025-07-22 7:24 ` [PATCH 2/6] block, bfq: don't grab queue_lock from io path Yu Kuai
2025-07-23 1:52 ` Damien Le Moal
2025-07-23 2:04 ` Yu Kuai
2025-07-22 7:24 ` [PATCH 3/6] block, bfq: switch to use elevator lock Yu Kuai
2025-07-23 1:53 ` Damien Le Moal
2025-07-22 7:24 ` [PATCH 4/6] elevator: factor elevator lock out of dispatch_request method Yu Kuai
2025-07-23 1:59 ` Damien Le Moal [this message]
2025-07-23 2:17 ` Yu Kuai
2025-07-23 2:42 ` Damien Le Moal
2025-07-23 2:51 ` Yu Kuai
2025-07-23 4:34 ` Damien Le Moal
2025-07-23 6:10 ` Yu Kuai
2025-07-22 7:24 ` [PATCH 5/6] blk-mq-sched: refactor __blk_mq_do_dispatch_sched() Yu Kuai
2025-07-22 7:24 ` [PATCH 6/6] blk-mq-sched: support request batch dispatching for sq elevator Yu Kuai
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=08c989bd-20d8-476c-af99-c9eb8065349d@kernel.org \
--to=dlemoal@kernel.org \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=hare@suse.de \
--cc=johnny.chenyi@huawei.com \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai1@huaweicloud.com \
--cc=yukuai3@huawei.com \
/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;
as well as URLs for NNTP newsgroup(s).