From: Ming Lei <ming.lei@redhat.com> To: Chao Leng <lengchao@huawei.com> Cc: Sagi Grimberg <sagi@grimberg.me>, Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@kernel.dk>, linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>, linux-nvme@lists.infradead.org Subject: Re: [PATCH v3 1/2] blk-mq: add async quiesce interface Date: Mon, 27 Jul 2020 14:32:20 +0800 [thread overview] Message-ID: <20200727063220.GA1144698@T590> (raw) In-Reply-To: <79ab699e-3f50-26c0-3c85-1962ae4dedac@huawei.com> On Mon, Jul 27, 2020 at 01:55:53PM +0800, Chao Leng wrote: > > > On 2020/7/27 11:50, Ming Lei wrote: > > On Mon, Jul 27, 2020 at 11:33:43AM +0800, Chao Leng wrote: > > > > > > > > > On 2020/7/27 10:08, Ming Lei wrote: > > > > > It is at the end and contains exactly what is needed to synchronize. Not > > > > The sync is simply single global synchronize_rcu(), and why bother to add > > > > extra >=40bytes for each hctx. > > > > > > > > > sure what you mean by reuse hctx->srcu? > > > > You already reuses hctx->srcu, but not see reason to add extra rcu_synchronize > > > > to each hctx for just simulating one single synchronize_rcu(). > > > > > > To sync srcu together, the extra bytes must be needed, seperate blocking > > > and non blocking queue to two hctx may be a not good choice. > > > > > > There is two choice: the struct rcu_synchronize is added in hctx or in srcu. > > > Though add rcu_synchronize in srcu has a weakness: the extra bytes is > > > not need if which do not need batch sync srcu, I still think it's better > > > for the SRCU to provide the batch synchronization interface. > > > > The 'struct rcu_synchronize' can be allocated from heap or even stack( > > if no too many NSs), which is just one shot sync and the API is supposed > > to be called in slow path. No need to allocate it as long lifetime variable. > > Especially 'struct srcu_struct' has already been too fat. > > Stack is not suitable, stack can not provide so many space for Stack is fine if number of NS is small, for example, most of times, there is just one NS. > many name space. Heap maybe a choice, but need to add abnormal treat > when alloc memory failed, Thus io pause time can not be ensured. > So the extra space may must be needed for batch srcu sync. In case of allocation failure, you can switch to synchronize_srcu() simply. Thanks, Ming
WARNING: multiple messages have this Message-ID (diff)
From: Ming Lei <ming.lei@redhat.com> To: Chao Leng <lengchao@huawei.com> Cc: Jens Axboe <axboe@kernel.dk>, Sagi Grimberg <sagi@grimberg.me>, linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, Keith Busch <kbusch@kernel.org>, Christoph Hellwig <hch@lst.de> Subject: Re: [PATCH v3 1/2] blk-mq: add async quiesce interface Date: Mon, 27 Jul 2020 14:32:20 +0800 [thread overview] Message-ID: <20200727063220.GA1144698@T590> (raw) In-Reply-To: <79ab699e-3f50-26c0-3c85-1962ae4dedac@huawei.com> On Mon, Jul 27, 2020 at 01:55:53PM +0800, Chao Leng wrote: > > > On 2020/7/27 11:50, Ming Lei wrote: > > On Mon, Jul 27, 2020 at 11:33:43AM +0800, Chao Leng wrote: > > > > > > > > > On 2020/7/27 10:08, Ming Lei wrote: > > > > > It is at the end and contains exactly what is needed to synchronize. Not > > > > The sync is simply single global synchronize_rcu(), and why bother to add > > > > extra >=40bytes for each hctx. > > > > > > > > > sure what you mean by reuse hctx->srcu? > > > > You already reuses hctx->srcu, but not see reason to add extra rcu_synchronize > > > > to each hctx for just simulating one single synchronize_rcu(). > > > > > > To sync srcu together, the extra bytes must be needed, seperate blocking > > > and non blocking queue to two hctx may be a not good choice. > > > > > > There is two choice: the struct rcu_synchronize is added in hctx or in srcu. > > > Though add rcu_synchronize in srcu has a weakness: the extra bytes is > > > not need if which do not need batch sync srcu, I still think it's better > > > for the SRCU to provide the batch synchronization interface. > > > > The 'struct rcu_synchronize' can be allocated from heap or even stack( > > if no too many NSs), which is just one shot sync and the API is supposed > > to be called in slow path. No need to allocate it as long lifetime variable. > > Especially 'struct srcu_struct' has already been too fat. > > Stack is not suitable, stack can not provide so many space for Stack is fine if number of NS is small, for example, most of times, there is just one NS. > many name space. Heap maybe a choice, but need to add abnormal treat > when alloc memory failed, Thus io pause time can not be ensured. > So the extra space may must be needed for batch srcu sync. In case of allocation failure, you can switch to synchronize_srcu() simply. Thanks, Ming _______________________________________________ Linux-nvme mailing list Linux-nvme@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2020-07-27 6:32 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-26 0:22 [PATCH v3 0/2] improve quiesce time for large amount of namespaces Sagi Grimberg 2020-07-26 0:22 ` Sagi Grimberg 2020-07-26 0:23 ` [PATCH v3 1/2] blk-mq: add async quiesce interface Sagi Grimberg 2020-07-26 0:23 ` Sagi Grimberg 2020-07-26 9:31 ` Ming Lei 2020-07-26 9:31 ` Ming Lei 2020-07-26 16:27 ` Sagi Grimberg 2020-07-26 16:27 ` Sagi Grimberg 2020-07-27 2:08 ` Ming Lei 2020-07-27 2:08 ` Ming Lei 2020-07-27 3:33 ` Chao Leng 2020-07-27 3:33 ` Chao Leng 2020-07-27 3:50 ` Ming Lei 2020-07-27 3:50 ` Ming Lei 2020-07-27 5:55 ` Chao Leng 2020-07-27 5:55 ` Chao Leng 2020-07-27 6:32 ` Ming Lei [this message] 2020-07-27 6:32 ` Ming Lei 2020-07-27 18:40 ` Sagi Grimberg 2020-07-27 18:40 ` Sagi Grimberg 2020-07-27 18:38 ` Sagi Grimberg 2020-07-27 18:38 ` Sagi Grimberg 2020-07-27 18:36 ` Sagi Grimberg 2020-07-27 18:36 ` Sagi Grimberg 2020-07-27 20:37 ` Jens Axboe 2020-07-27 20:37 ` Jens Axboe 2020-07-27 21:00 ` Sagi Grimberg 2020-07-27 21:00 ` Sagi Grimberg 2020-07-27 21:05 ` Jens Axboe 2020-07-27 21:05 ` Jens Axboe 2020-07-27 21:21 ` Keith Busch 2020-07-27 21:21 ` Keith Busch 2020-07-27 21:30 ` Jens Axboe 2020-07-27 21:30 ` Jens Axboe 2020-07-28 1:09 ` Ming Lei 2020-07-28 1:09 ` Ming Lei 2020-07-26 0:23 ` [PATCH v3 2/2] nvme: improve quiesce time for large amount of namespaces Sagi Grimberg 2020-07-26 0:23 ` Sagi Grimberg
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=20200727063220.GA1144698@T590 \ --to=ming.lei@redhat.com \ --cc=axboe@kernel.dk \ --cc=hch@lst.de \ --cc=kbusch@kernel.org \ --cc=lengchao@huawei.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-nvme@lists.infradead.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: linkBe 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.