mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: Yu Kuai <yukuai1@huaweicloud.com>,
	hare@suse.de, jack@suse.cz, bvanassche@acm.org, 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 v3 1/5] blk-mq-sched: introduce high level elevator lock
Date: Mon, 11 Aug 2025 09:44:20 +0900	[thread overview]
Message-ID: <61c62ef0-4dde-4c14-8039-213258d3c6ae@kernel.org> (raw)
In-Reply-To: <20250806085720.4040507-2-yukuai1@huaweicloud.com>

On 8/6/25 17:57, 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.
> 
> 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.
> 
> Hence introduce a new high level elevator lock, currently it is protecting
> dispatch_request only. Following patches will convert mq-deadline and bfq
> to use this lock and finally support request batch dispatching by calling
> the method multiple time while holding the lock.
> 
> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> ---
>  block/blk-mq-sched.c |  9 ++++++++-
>  block/elevator.c     |  1 +
>  block/elevator.h     | 14 ++++++++++++--
>  3 files changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
> index 55a0fd105147..1a2da5edbe13 100644
> --- a/block/blk-mq-sched.c
> +++ b/block/blk-mq-sched.c
> @@ -113,7 +113,14 @@ static int __blk_mq_do_dispatch_sched(struct blk_mq_hw_ctx *hctx)
>  		if (budget_token < 0)
>  			break;
>  
> -		rq = e->type->ops.dispatch_request(hctx);
> +		if (blk_queue_sq_sched(q)) {
> +			elevator_lock(e);
> +			rq = e->type->ops.dispatch_request(hctx);
> +			elevator_unlock(e);

I do not think this is safe for bfq since bfq uses the irqsave/irqrestore spin
lock variant. If it is safe, this needs a big comment block explaining why
and/or the rules regarding the scheduler use of this lock.

> +		} else {
> +			rq = e->type->ops.dispatch_request(hctx);
> +		}
> +
>  		if (!rq) {
>  			blk_mq_put_dispatch_budget(q, budget_token);
>  			/*
> diff --git a/block/elevator.c b/block/elevator.c
> index 88f8f36bed98..45303af0ca73 100644
> --- a/block/elevator.c
> +++ b/block/elevator.c
> @@ -144,6 +144,7 @@ struct elevator_queue *elevator_alloc(struct request_queue *q,
>  	eq->type = e;
>  	kobject_init(&eq->kobj, &elv_ktype);
>  	mutex_init(&eq->sysfs_lock);
> +	spin_lock_init(&eq->lock);
>  	hash_init(eq->hash);
>  
>  	return eq;
> diff --git a/block/elevator.h b/block/elevator.h
> index a07ce773a38f..81f7700b0339 100644
> --- a/block/elevator.h
> +++ b/block/elevator.h
> @@ -110,12 +110,12 @@ struct request *elv_rqhash_find(struct request_queue *q, sector_t offset);
>  /*
>   * each queue has an elevator_queue associated with it
>   */
> -struct elevator_queue
> -{
> +struct elevator_queue {
>  	struct elevator_type *type;
>  	void *elevator_data;
>  	struct kobject kobj;
>  	struct mutex sysfs_lock;
> +	spinlock_t lock;
>  	unsigned long flags;
>  	DECLARE_HASHTABLE(hash, ELV_HASH_BITS);
>  };
> @@ -124,6 +124,16 @@ struct elevator_queue
>  #define ELEVATOR_FLAG_DYING		1
>  #define ELEVATOR_FLAG_ENABLE_WBT_ON_EXIT	2
>  
> +#define elevator_lock(e)		spin_lock(&(e)->lock)
> +#define elevator_unlock(e)		spin_unlock(&(e)->lock)
> +#define elevator_lock_irq(e)		spin_lock_irq(&(e)->lock)
> +#define elevator_unlock_irq(e)		spin_unlock_irq(&(e)->lock)
> +#define elevator_lock_irqsave(e, flags) \
> +	spin_lock_irqsave(&(e)->lock, flags)
> +#define elevator_unlock_irqrestore(e, flags) \
> +	spin_unlock_irqrestore(&(e)->lock, flags)
> +#define elevator_lock_assert_held(e)	lockdep_assert_held(&(e)->lock)
> +
>  /*
>   * block elevator interface
>   */


-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2025-08-11  0:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-06  8:57 [PATCH v3 0/5] blk-mq-sched: support request batch dispatching for sq elevator Yu Kuai
2025-08-06  8:57 ` [PATCH v3 1/5] blk-mq-sched: introduce high level elevator lock Yu Kuai
2025-08-11  0:44   ` Damien Le Moal [this message]
2025-08-11  1:01     ` Yu Kuai
2025-08-11  3:53       ` Damien Le Moal
2025-08-11  4:25         ` Yu Kuai
2025-08-11  4:34           ` Damien Le Moal
2025-08-11  6:17             ` Yu Kuai
2025-08-06  8:57 ` [PATCH v3 2/5] mq-deadline: switch to use " Yu Kuai
2025-08-06  8:57 ` [PATCH v3 3/5] block, bfq: " Yu Kuai
2025-08-06  8:57 ` [PATCH v3 4/5] blk-mq-sched: refactor __blk_mq_do_dispatch_sched() Yu Kuai
2025-08-06  8:57 ` [PATCH v3 5/5] 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=61c62ef0-4dde-4c14-8039-213258d3c6ae@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=cgroups@vger.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

all inboxes | Powered by JetHome®