From: Christoph Hellwig <hch@lst.de>
To: Ming Lei <ming.lei@redhat.com>
Cc: "Nilay Shroff" <nilay@linux.ibm.com>,
"Jens Axboe" <axboe@kernel.dk>,
linux-block@vger.kernel.org,
"Shinichiro Kawasaki" <shinichiro.kawasaki@wdc.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Christoph Hellwig" <hch@lst.de>
Subject: Re: [PATCH V2 07/20] block: prevent adding/deleting disk during updating nr_hw_queues
Date: Tue, 22 Apr 2025 09:04:32 +0200 [thread overview]
Message-ID: <20250422070432.GB30990@lst.de> (raw)
In-Reply-To: <aAWv3NPtNIKKvJZc@fedora>
On Mon, Apr 21, 2025 at 10:39:24AM +0800, Ming Lei wrote:
> > In my view, RCU is optimized for read-heavy workloads with:
> > - Non-blocking readers
>
> srcu allows blocking reader
It does. But it's certainly not optimized for long blocking readers.
> Basically I agree with you that rwsem(instead of rwlock) should match with
> this case in theory, but I feel that rwsem is stronger than srcu from lock
> viewpoint, and we will add new dependency if rwsem is held inside
> ->store(), such as the following splat.
How does manually implementing a reader/write lock using SRCU avoid
that dependency vs just hiding it?
I'd rather sort this out as a rwsem is very natural her as Nilay pointed
out, and also avoids the whole giv up and retry pattern.
next prev parent reply other threads:[~2025-04-22 7:04 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-18 16:36 [PATCH V2 00/20] block: unify elevator changing and fix lockdep warning Ming Lei
2025-04-18 16:36 ` [PATCH V2 01/20] block: move blk_mq_add_queue_tag_set() after blk_mq_map_swqueue() Ming Lei
2025-04-19 8:57 ` Yu Kuai
2025-04-19 10:25 ` Nilay Shroff
2025-04-21 12:31 ` Christoph Hellwig
2025-04-22 6:00 ` Hannes Reinecke
2025-04-18 16:36 ` [PATCH V2 02/20] block: move ELEVATOR_FLAG_DISABLE_WBT as request queue flag Ming Lei
2025-04-19 8:59 ` Yu Kuai
2025-04-19 14:52 ` Nilay Shroff
2025-04-21 12:33 ` Christoph Hellwig
2025-04-22 6:01 ` Hannes Reinecke
2025-04-18 16:36 ` [PATCH V2 03/20] block: don't call freeze queue in elevator_switch() and elevator_disable() Ming Lei
2025-04-19 9:01 ` Yu Kuai
2025-04-21 12:34 ` Christoph Hellwig
2025-04-22 4:00 ` Ming Lei
2025-04-22 7:00 ` Christoph Hellwig
2025-04-22 6:02 ` Hannes Reinecke
2025-04-18 16:36 ` [PATCH V2 04/20] block: add two helpers for registering/un-registering sched debugfs Ming Lei
2025-04-19 9:18 ` Yu Kuai
2025-04-19 10:27 ` Nilay Shroff
2025-04-21 12:36 ` Christoph Hellwig
2025-04-22 6:04 ` Hannes Reinecke
2025-04-18 16:36 ` [PATCH V2 05/20] block: move sched debugfs register into elvevator_register_queue Ming Lei
2025-04-19 9:28 ` Yu Kuai
2025-04-19 10:28 ` Nilay Shroff
2025-04-21 12:37 ` Christoph Hellwig
2025-04-22 6:06 ` Hannes Reinecke
2025-04-18 16:36 ` [PATCH V2 06/20] block: add & pass 'struct gendisk_data' for retrying add/del disk in updating nr_hw_queues Ming Lei
2025-04-18 16:36 ` [PATCH V2 07/20] block: prevent adding/deleting disk during " Ming Lei
2025-04-19 11:20 ` Nilay Shroff
2025-04-21 2:39 ` Ming Lei
2025-04-22 7:04 ` Christoph Hellwig [this message]
2025-04-22 9:29 ` Ming Lei
2025-04-22 10:26 ` Nilay Shroff
2025-04-18 16:36 ` [PATCH V2 08/20] block: don't allow to switch elevator if updating nr_hw_queues is in-progress Ming Lei
2025-04-19 11:22 ` Nilay Shroff
2025-04-18 16:36 ` [PATCH V2 09/20] block: simplify elevator rebuild for updating nr_hw_queues Ming Lei
2025-04-19 11:25 ` Nilay Shroff
2025-04-18 16:36 ` [PATCH V2 10/20] block: add helper of elevator_change() Ming Lei
2025-04-18 16:36 ` [PATCH V2 11/20] block: move blk_unregister_queue() & device_del() after freeze wait Ming Lei
2025-04-19 12:38 ` Nilay Shroff
2025-04-22 10:50 ` Ming Lei
2025-04-18 16:36 ` [PATCH V2 12/20] block: add `struct elv_change_ctx` for unifying elevator_change Ming Lei
2025-04-19 12:40 ` Nilay Shroff
2025-04-22 7:07 ` Christoph Hellwig
2025-04-22 8:36 ` Ming Lei
2025-04-23 7:10 ` Christoph Hellwig
2025-04-18 16:36 ` [PATCH V2 13/20] block: unifying elevator change Ming Lei
2025-04-19 13:26 ` Nilay Shroff
2025-04-24 9:02 ` Ming Lei
2025-04-18 16:36 ` [PATCH V2 14/20] block: pass elevator_queue to elv_register_queue & unregister_queue Ming Lei
2025-04-19 13:28 ` Nilay Shroff
2025-04-18 16:36 ` [PATCH V2 15/20] block: fail to show/store elevator sysfs attribute if elevator is dying Ming Lei
2025-04-19 13:45 ` Nilay Shroff
2025-04-18 16:36 ` [PATCH V2 16/20] block: move elv_register[unregister]_queue out of elevator_lock Ming Lei
2025-04-19 13:55 ` Nilay Shroff
2025-04-22 10:53 ` Ming Lei
2025-04-22 11:06 ` Nilay Shroff
2025-04-22 11:14 ` Ming Lei
2025-04-18 16:36 ` [PATCH V2 17/20] block: move debugfs/sysfs register out of freezing queue Ming Lei
2025-04-19 13:57 ` Nilay Shroff
2025-04-18 16:36 ` [PATCH V2 18/20] block: remove several ->elevator_lock Ming Lei
2025-04-19 14:17 ` Nilay Shroff
2025-04-18 16:37 ` [PATCH V2 19/20] block: move hctx cpuhp add/del out of queue freezing Ming Lei
2025-04-19 14:20 ` Nilay Shroff
2025-04-18 16:37 ` [PATCH V2 20/20] block: move wbt_enable_default() out of queue freezing from sched ->exit() Ming Lei
2025-04-19 14:39 ` Nilay Shroff
2025-04-21 7:27 ` Ming Lei
2025-04-22 6:14 ` Nilay Shroff
2025-04-22 8:13 ` Ming Lei
2025-04-22 9:27 ` Nilay Shroff
2025-04-22 9:33 ` Ming Lei
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=20250422070432.GB30990@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=nilay@linux.ibm.com \
--cc=shinichiro.kawasaki@wdc.com \
--cc=thomas.hellstrom@linux.intel.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