All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <tom.leiming@gmail.com>
To: Qiliang Yuan <odys.yuan@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>, Yu Kuai <yukuai@fygo.io>,
	Hannes Reinecke <hare@suse.de>,
	"Martin K. Petersen" <mkp@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] blk-mq: share one tags_srcu instance across all tag sets
Date: Thu, 15 Oct 2026 23:17:55 -0500	[thread overview]
Message-ID: <atGlc3-aaLfIHJH4@fedora-laptop> (raw)
In-Reply-To: <20261001-bug-blk-mq-global-tags-srcu-v1-1-e8415da10d1b@gmail.com>

On Thu, Oct 01, 2026 at 05:17:50PM +0800, Qiliang Yuan wrote:
> Freed request pages and flush queues are handed to call_srcu() so that
> concurrent tag iterators never see them disappear. Each tag set embeds
> its own srcu_struct for this, which blk_mq_free_tag_set() has to drain
> with srcu_barrier() before cleanup_srcu_struct(). The barrier waits for
> a full SRCU grace period even when the callbacks are long done, adding
> 1-3 ms to every tag set teardown. Drivers that free tag sets under a
> lock make it worse: ublk does it under the global ublk_ctl_mutex, so
> deleting devices from many threads serializes on that grace period.
> 
> The callbacks free memory that only blk-mq owns. They touch neither
> the tag set nor driver code, so they don't need a per-set domain.
> Replace the per-set srcu_struct with a single global one. Freeing a tag
> set no longer waits for a grace period, and each tag set no longer
> allocates per-CPU SRCU state. The read side is unchanged. The only cost
> is that a long-running iterator can now delay these frees for other tag
> sets too, which only postpones freeing memory.
> 
> On 7.3-rc5 in a 16-vCPU VM, with 1 queue and depth 16 per ublk device,
> median of 3 runs (5 for the 16-thread null_blk case):
> 
>                                        before     after
>   ublk DEL_DEV p50, serial             3.45 ms    0.17 ms
>   ublk delete 1000 devices, serial     19.5 s     14.9 s
>   ublk delete 4000 devices, 16 thr     19.0 s     2.9 s
>   null_blk destroy 500 devs, serial    9.97 s     9.25 s
>   null_blk destroy 256 devs, 16 thr    5.15 s     4.30 s
> 
> Fixes: ad0d05dbddc1 ("blk-mq: Defer freeing of tags page_list to SRCU callback")
> Signed-off-by: Qiliang Yuan <odys.yuan@gmail.com>

Reviewed-by: Ming Lei <tom.leiming@gmail.com>


Thanks,
Ming

  reply	other threads:[~2026-10-16  4:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-01  9:17 [PATCH 0/2] blk-mq: stop waiting for an SRCU grace period when freeing a tag set Qiliang Yuan
2026-10-01  9:17 ` [PATCH 1/2] blk-mq: share one tags_srcu instance across all tag sets Qiliang Yuan
2026-10-16  4:17   ` Ming Lei [this message]
2026-10-01  9:17 ` [PATCH 2/2] blk-mq: drop the tag_set argument from blk_mq_free_rq_map/tags Qiliang Yuan
2026-10-16  4:18   ` Ming Lei
2026-10-01 16:10 ` [PATCH 0/2] blk-mq: stop waiting for an SRCU grace period when freeing a tag set Paul E. McKenney
2026-10-15  2:26 ` Qiliang Yuan
2026-10-16 14:28 ` Jens Axboe

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=atGlc3-aaLfIHJH4@fedora-laptop \
    --to=tom.leiming@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=hare@suse.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkp@kernel.org \
    --cc=odys.yuan@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=yukuai@fygo.io \
    /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.