From: Christoph Hellwig <hch@lst.de>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, Chao Leng <lengchao@huawei.com>,
linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
sagi@grimberg.me, kbusch@kernel.org, ming.lei@redhat.com,
axboe@kernel.dk
Subject: Re: [PATCH v2 1/2] blk-mq: add tagset quiesce interface
Date: Tue, 18 Oct 2022 07:19:56 +0200 [thread overview]
Message-ID: <20221018051956.GA18802@lst.de> (raw)
In-Reply-To: <20221017224115.GJ5600@paulmck-ThinkPad-P17-Gen-1>
On Mon, Oct 17, 2022 at 03:41:15PM -0700, Paul E. McKenney wrote:
> Then the big question is "how long do the SRCU readers run?"
>
> If all of the readers ran for exactly the same duration, there would be
> little point in having more than one srcu_struct.
The SRCU readers are the I/O dispatch, which will have quite similar
runtimes for the different queues.
> If the kernel knew up front how long the SRCU readers for a given entry
> would run, it could provide an srcu_struct structure for each duration.
> For a (fanciful) example, you could have one srcu_struct structure for
> SSDs, another for rotating rust, a third for LAN-attached storage, and
> a fourth for WAN-attached storage. Maybe a fifth for lunar-based storage.
All the different request_queues in a tag_set are for the same device.
There might be some corner cases like storare arrays where they have
different latencies. But we're not even waiting for the I/O completion
here, this just protects the submission.
> Does that help, or am I off in the weeds here?
I think this was very helpful, and at least to be moving the srcu_struct
to the tag_set sounds like a good idea to explore.
Ming, anything I might have missed?
next prev parent reply other threads:[~2022-10-18 5:20 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-13 9:44 [PATCH v2 0/2] improve nvme quiesce time for large amount of namespaces Chao Leng
2022-10-13 9:44 ` [PATCH v2 1/2] blk-mq: add tagset quiesce interface Chao Leng
2022-10-13 10:28 ` Sagi Grimberg
2022-10-14 2:09 ` Chao Leng
2022-10-17 13:43 ` Christoph Hellwig
2022-10-18 9:51 ` Chao Leng
2022-10-17 13:39 ` Christoph Hellwig
2022-10-17 13:42 ` Christoph Hellwig
2022-10-18 8:39 ` Sagi Grimberg
2022-10-18 8:55 ` Christoph Hellwig
2022-10-18 9:06 ` Sagi Grimberg
2022-10-18 11:05 ` Christoph Hellwig
2022-10-18 9:52 ` Chao Leng
2022-10-17 15:21 ` Paul E. McKenney
2022-10-17 15:31 ` Christoph Hellwig
2022-10-17 22:41 ` Paul E. McKenney
2022-10-18 5:19 ` Christoph Hellwig [this message]
2022-10-19 0:35 ` Ming Lei
2022-10-19 7:15 ` Sagi Grimberg
2022-10-19 7:25 ` Christoph Hellwig
2022-10-19 7:27 ` Christoph Hellwig
2022-10-19 7:30 ` Sagi Grimberg
2022-10-19 7:32 ` Christoph Hellwig
2022-10-19 7:57 ` Sagi Grimberg
2022-10-19 8:17 ` Christoph Hellwig
2022-10-19 8:29 ` Sagi Grimberg
2022-10-18 9:52 ` Chao Leng
2022-10-18 15:04 ` Paul E. McKenney
2022-10-19 2:39 ` Chao Leng
2022-10-18 9:52 ` Chao Leng
2022-10-13 9:44 ` [PATCH v2 2/2] nvme: use blk_mq_[un]quiesce_tagset Chao Leng
2022-10-13 10:22 ` Sagi Grimberg
2022-10-14 2:09 ` Chao Leng
2022-10-17 13:48 ` Christoph Hellwig
2022-10-13 14:32 ` [PATCH v2 0/2] improve nvme quiesce time for large amount of namespaces Chaitanya Kulkarni
2022-10-14 2:12 ` Chao Leng
2022-10-15 0:30 ` Chaitanya Kulkarni
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=20221018051956.GA18802@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=kbusch@kernel.org \
--cc=lengchao@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=ming.lei@redhat.com \
--cc=paulmck@kernel.org \
--cc=sagi@grimberg.me \
/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.