From: Bart Van Assche <bvanassche@acm.org>
To: Yu Kuai <yukuai1@huaweicloud.com>,
dlemoal@kernel.org, hare@suse.de, jack@suse.cz, 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 v2 4/5] blk-mq-sched: refactor __blk_mq_do_dispatch_sched()
Date: Wed, 30 Jul 2025 11:32:38 -0700 [thread overview]
Message-ID: <d5507645-6ad6-48a1-b429-c5bf7fda9523@acm.org> (raw)
In-Reply-To: <20250730082207.4031744-5-yukuai1@huaweicloud.com>
On 7/30/25 1:22 AM, Yu Kuai wrote:
> Introduce struct sched_dispatch_ctx, and split the helper into
> elevator_dispatch_one_request() and elevator_finish_dispatch(). Also
> and comments about the non-error return value.
and -> add
> +struct sched_dispatch_ctx {
> + struct blk_mq_hw_ctx *hctx;
> + struct elevator_queue *e;
> + struct request_queue *q;
'e' is always equal to q->elevator so I'm not sure whether it's worth to
have the member 'e'?
> +static bool elevator_can_dispatch(struct sched_dispatch_ctx *ctx)
> +{
> + if (ctx->e->type->ops.has_work &&
> + !ctx->e->type->ops.has_work(ctx->hctx))
> + return false;
>
> - if (!list_empty_careful(&hctx->dispatch)) {
> - busy = true;
> - break;
> - }
> + if (!list_empty_careful(&ctx->hctx->dispatch)) {
> + ctx->busy = true;
> + return false;
> + }
>
> - budget_token = blk_mq_get_dispatch_budget(q);
> - if (budget_token < 0)
> - break;
> + return true;
> +}
Shouldn't all function names in this file start with the blk_mq_ prefix?
Additionally, please rename elevator_can_dispatch() into
elevator_should_dispatch(). I think the latter name better reflects the
purpose of this function.
> + if (sq_sched)
> + spin_lock_irq(&ctx->e->lock);
> + rq = ctx->e->type->ops.dispatch_request(ctx->hctx);
> + if (sq_sched)
> + spin_unlock_irq(&ctx->e->lock);
Same comment here as on patch 1/5: code like the above makes it
harder than necessary for static analyzers to verify this code.
>
> + if (!rq) {
> + blk_mq_put_dispatch_budget(ctx->q, budget_token);
> /*
> - * If we cannot get tag for the request, stop dequeueing
> - * requests from the IO scheduler. We are unlikely to be able
> - * to submit them anyway and it creates false impression for
> - * scheduling heuristics that the device can take more IO.
> + * We're releasing without dispatching. Holding the
> + * budget could have blocked any "hctx"s with the
> + * same queue and if we didn't dispatch then there's
> + * no guarantee anyone will kick the queue. Kick it
> + * ourselves.
> */
Please keep the original comment. To me the new comment seems less clear
than the existing comment.
> +static int __blk_mq_do_dispatch_sched(struct blk_mq_hw_ctx *hctx)
> +{
> + unsigned int max_dispatch;
> + struct sched_dispatch_ctx ctx = {
> + .hctx = hctx,
> + .q = hctx->queue,
> + .e = hctx->queue->elevator,
> + };
> +
> + INIT_LIST_HEAD(&ctx.rq_list);
Please remove the INIT_LIST_HEAD() invocation and add the following in
the ctx declaration:
.rq_list = LIST_HEAD_INIT(ctx.rq_list),
This is a common pattern in kernel code. The following grep command
yields about 200 results:
$ git grep -nH '= LIST_HEAD_INIT.*\.'
Otherwise this patch looks good to me.
Thanks,
Bart.
next prev parent reply other threads:[~2025-07-30 18:32 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-30 8:22 [PATCH v2 0/5] blk-mq-sched: support request batch dispatching for sq elevator Yu Kuai
2025-07-30 8:22 ` [PATCH v2 1/5] blk-mq-sched: introduce high level elevator lock Yu Kuai
2025-07-30 17:19 ` Bart Van Assche
2025-07-30 17:59 ` Yu Kuai
2025-07-31 6:17 ` Hannes Reinecke
2025-07-30 8:22 ` [PATCH v2 2/5] mq-deadline: switch to use " Yu Kuai
2025-07-30 17:21 ` Bart Van Assche
2025-07-30 18:01 ` Yu Kuai
2025-07-30 18:10 ` Bart Van Assche
2025-07-31 6:20 ` Hannes Reinecke
2025-07-31 6:22 ` Damien Le Moal
2025-07-31 6:32 ` Yu Kuai
2025-07-31 7:04 ` Damien Le Moal
2025-07-31 7:14 ` Yu Kuai
2025-07-30 8:22 ` [PATCH v2 3/5] block, bfq: " Yu Kuai
2025-07-30 17:24 ` Bart Van Assche
2025-07-31 6:22 ` Hannes Reinecke
2025-07-30 8:22 ` [PATCH v2 4/5] blk-mq-sched: refactor __blk_mq_do_dispatch_sched() Yu Kuai
2025-07-30 18:32 ` Bart Van Assche [this message]
2025-07-31 0:49 ` Yu Kuai
2025-07-30 8:22 ` [PATCH v2 5/5] blk-mq-sched: support request batch dispatching for sq elevator Yu Kuai
2025-07-31 8:18 ` [PATCH v2 0/5] " Ming Lei
2025-07-31 8:42 ` Yu Kuai
2025-07-31 9:25 ` Ming Lei
2025-07-31 9:33 ` Yu Kuai
2025-07-31 10: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=d5507645-6ad6-48a1-b429-c5bf7fda9523@acm.org \
--to=bvanassche@acm.org \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=dlemoal@kernel.org \
--cc=hare@suse.de \
--cc=jack@suse.cz \
--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