From: Sagi Grimberg <sagi@grimberg.me>
To: Ming Lei <ming.lei@redhat.com>, Chao Leng <lengchao@huawei.com>
Cc: linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
kbusch@kernel.org, axboe@fb.com, hch@lst.de
Subject: Re: [PATCH v2 0/3] reduce quiesce time for lots of name spaces
Date: Fri, 7 Aug 2020 09:37:16 -0700 [thread overview]
Message-ID: <d3bedf2b-58d5-667c-7f87-6334772a5772@grimberg.me> (raw)
In-Reply-To: <20200807134932.GA2122627@T590>
>> nvme_stop_queues quiesce queues for all name spaces, now quiesce one by
>> one, if there is lots of name spaces, sync wait long time(more than 10s).
>> Multipath can not fail over to retry quickly, cause io pause long time.
>> This is not expected.
>> To reduce quiesce time, we introduce async mechanism for sync SRCUs
>> and quiesce queue.
>>
>
> Frankly speaking, I prefer to replace SRCU with percpu_refcount:
>
> - percpu_refcount has much less memory footprint than SRCU, so we can simply
> move percpu_refcount into request_queue, instead of adding more bytes
> into each hctx by this patch
>
> - percpu_ref_get()/percpu_ref_put() isn't slower than srcu_read_lock()/srcu_read_unlock().
>
> - with percpu_refcount, we can remove 'srcu_idx' from hctx_lock/hctx_unlock()
Ming, I don't have an issue with your preference, but I don't want to
tie it to what Chao is attempting to fix.
So we should either move forward with an srcu approach, or you please
provide evidence to your claims if you are replacing the fast-path
synchronization mechanism, as this warrants a very good justification.
next prev parent reply other threads:[~2020-08-07 16:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-07 9:05 [PATCH v2 0/3] reduce quiesce time for lots of name spaces Chao Leng
2020-08-07 13:49 ` Ming Lei
2020-08-07 16:37 ` Sagi Grimberg [this message]
2020-08-10 2:17 ` Chao Leng
2020-08-10 3:15 ` Ming Lei
2020-08-11 3:13 ` Chao Leng
2020-08-11 20:53 ` 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=d3bedf2b-58d5-667c-7f87-6334772a5772@grimberg.me \
--to=sagi@grimberg.me \
--cc=axboe@fb.com \
--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 \
/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