All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sagi Grimberg <sagi@grimberg.me>
To: Ming Lei <ming.lei@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
	Chao Leng <lengchao@huawei.com>, Keith Busch <kbusch@kernel.org>,
	Ming Lin <mlin@kernel.org>
Subject: Re: [PATCH v5 1/2] blk-mq: add tagset quiesce interface
Date: Tue, 28 Jul 2020 02:43:06 -0700	[thread overview]
Message-ID: <6a678d5d-22b2-5238-92c5-d68e2aafeb9e@grimberg.me> (raw)
In-Reply-To: <44f07df6-3107-3e7f-ee02-7bc43293ee6b@grimberg.me>


>>>>> I like the tagset based interface.  But the idea of doing a per-hctx
>>>>> allocation and wait doesn't seem very scalable.
>>>>>
>>>>> Paul, do you have any good idea for an interface that waits on
>>>>> multiple srcu heads?  As far as I can tell we could just have a single
>>>>> global completion and counter, and each call_srcu would just just
>>>>> decrement it and then the final one would do the wakeup.  It would 
>>>>> just
>>>>> be great to figure out a way to keep the struct rcu_synchronize and
>>>>> counter on stack to avoid an allocation.
>>>>>
>>>>> But if we can't do with an on-stack object I'd much rather just embedd
>>>>> the rcu_head in the hw_ctx.
>>>>
>>>> I think we can do that, please see the following patch which is 
>>>> against Sagi's V5:
>>>
>>> I don't think you can send a single rcu_head to multiple call_srcu 
>>> calls.
>>
>> OK, then one variant is to put the rcu_head into blk_mq_hw_ctx, and put
>> rcu_synchronize into blk_mq_tag_set.
> 
> I can cook up a spin,

Nope.. spoke too soon, the rcu_head needs to be in a context that has
access to the counter (which is what you called blk_mq_srcu_sync).
you want to add also a pointer to hctx? that is almost as big as
rcu_synchronize...

WARNING: multiple messages have this Message-ID (diff)
From: Sagi Grimberg <sagi@grimberg.me>
To: Ming Lei <ming.lei@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
	Chao Leng <lengchao@huawei.com>, Keith Busch <kbusch@kernel.org>,
	Ming Lin <mlin@kernel.org>, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v5 1/2] blk-mq: add tagset quiesce interface
Date: Tue, 28 Jul 2020 02:43:06 -0700	[thread overview]
Message-ID: <6a678d5d-22b2-5238-92c5-d68e2aafeb9e@grimberg.me> (raw)
In-Reply-To: <44f07df6-3107-3e7f-ee02-7bc43293ee6b@grimberg.me>


>>>>> I like the tagset based interface.  But the idea of doing a per-hctx
>>>>> allocation and wait doesn't seem very scalable.
>>>>>
>>>>> Paul, do you have any good idea for an interface that waits on
>>>>> multiple srcu heads?  As far as I can tell we could just have a single
>>>>> global completion and counter, and each call_srcu would just just
>>>>> decrement it and then the final one would do the wakeup.  It would 
>>>>> just
>>>>> be great to figure out a way to keep the struct rcu_synchronize and
>>>>> counter on stack to avoid an allocation.
>>>>>
>>>>> But if we can't do with an on-stack object I'd much rather just embedd
>>>>> the rcu_head in the hw_ctx.
>>>>
>>>> I think we can do that, please see the following patch which is 
>>>> against Sagi's V5:
>>>
>>> I don't think you can send a single rcu_head to multiple call_srcu 
>>> calls.
>>
>> OK, then one variant is to put the rcu_head into blk_mq_hw_ctx, and put
>> rcu_synchronize into blk_mq_tag_set.
> 
> I can cook up a spin,

Nope.. spoke too soon, the rcu_head needs to be in a context that has
access to the counter (which is what you called blk_mq_srcu_sync).
you want to add also a pointer to hctx? that is almost as big as
rcu_synchronize...

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

  reply	other threads:[~2020-07-28  9:43 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27 23:10 [PATCH v5 0/2] improve nvme quiesce time for large amount of namespaces Sagi Grimberg
2020-07-27 23:10 ` Sagi Grimberg
2020-07-27 23:10 ` [PATCH v5 1/2] blk-mq: add tagset quiesce interface Sagi Grimberg
2020-07-27 23:10   ` Sagi Grimberg
2020-07-27 23:32   ` Keith Busch
2020-07-27 23:32     ` Keith Busch
2020-07-28  0:12     ` Sagi Grimberg
2020-07-28  0:12       ` Sagi Grimberg
2020-07-28  1:40   ` Ming Lei
2020-07-28  1:40     ` Ming Lei
2020-07-28  1:51     ` Jens Axboe
2020-07-28  1:51       ` Jens Axboe
2020-07-28  2:17       ` Ming Lei
2020-07-28  2:17         ` Ming Lei
2020-07-28  2:23         ` Jens Axboe
2020-07-28  2:23           ` Jens Axboe
2020-07-28  2:28           ` Ming Lei
2020-07-28  2:28             ` Ming Lei
2020-07-28  2:32             ` Jens Axboe
2020-07-28  2:32               ` Jens Axboe
2020-07-28  3:29               ` Sagi Grimberg
2020-07-28  3:29                 ` Sagi Grimberg
2020-07-28  3:25     ` Sagi Grimberg
2020-07-28  3:25       ` Sagi Grimberg
2020-07-28  7:18   ` Christoph Hellwig
2020-07-28  7:18     ` Christoph Hellwig
2020-07-28  7:48     ` Sagi Grimberg
2020-07-28  7:48       ` Sagi Grimberg
2020-07-28  9:16     ` Ming Lei
2020-07-28  9:16       ` Ming Lei
2020-07-28  9:24       ` Sagi Grimberg
2020-07-28  9:24         ` Sagi Grimberg
2020-07-28  9:33         ` Ming Lei
2020-07-28  9:33           ` Ming Lei
2020-07-28  9:37           ` Sagi Grimberg
2020-07-28  9:37             ` Sagi Grimberg
2020-07-28  9:43             ` Sagi Grimberg [this message]
2020-07-28  9:43               ` Sagi Grimberg
2020-07-28 10:10               ` Ming Lei
2020-07-28 10:10                 ` Ming Lei
2020-07-28 10:57                 ` Christoph Hellwig
2020-07-28 10:57                   ` Christoph Hellwig
2020-07-28 14:13                 ` Paul E. McKenney
2020-07-28 14:13                   ` Paul E. McKenney
2020-07-28 10:58             ` Christoph Hellwig
2020-07-28 10:58               ` Christoph Hellwig
2020-07-28 16:25               ` Sagi Grimberg
2020-07-28 16:25                 ` Sagi Grimberg
2020-07-28 13:54         ` Paul E. McKenney
2020-07-28 13:54           ` Paul E. McKenney
2020-07-28 23:46           ` Sagi Grimberg
2020-07-28 23:46             ` Sagi Grimberg
2020-07-29  0:31             ` Paul E. McKenney
2020-07-29  0:31               ` Paul E. McKenney
2020-07-29  0:43               ` Sagi Grimberg
2020-07-29  0:43                 ` Sagi Grimberg
2020-07-29  0:59                 ` Keith Busch
2020-07-29  0:59                   ` Keith Busch
2020-07-29  4:39                   ` Sagi Grimberg
2020-07-29  4:39                     ` Sagi Grimberg
2020-08-07  9:04                     ` Chao Leng
2020-08-07  9:04                       ` Chao Leng
2020-08-07  9:24                       ` Ming Lei
2020-08-07  9:24                         ` Ming Lei
2020-08-07  9:35                         ` Chao Leng
2020-08-07  9:35                           ` Chao Leng
2020-07-29  4:10                 ` Paul E. McKenney
2020-07-29  4:10                   ` Paul E. McKenney
2020-07-29  4:37                   ` Sagi Grimberg
2020-07-29  4:37                     ` Sagi Grimberg
2020-07-27 23:10 ` [PATCH v5 2/2] nvme: use blk_mq_[un]quiesce_tagset Sagi Grimberg
2020-07-27 23:10   ` Sagi Grimberg
2020-07-28  0:54   ` Sagi Grimberg
2020-07-28  0:54     ` Sagi Grimberg
2020-07-28  3:21     ` Chao Leng
2020-07-28  3:21       ` Chao Leng
2020-07-28  3:34       ` Sagi Grimberg
2020-07-28  3:34         ` Sagi Grimberg
2020-07-28  3:51         ` Chao Leng
2020-07-28  3:51           ` Chao Leng

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=6a678d5d-22b2-5238-92c5-d68e2aafeb9e@grimberg.me \
    --to=sagi@grimberg.me \
    --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=ming.lei@redhat.com \
    --cc=mlin@kernel.org \
    --cc=paulmck@kernel.org \
    /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.