On Tue, Apr 22, 2025 at 09:04:32AM +0200, Christoph Hellwig wrote: > 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. Thinking of further, the warning triggered from rwsem is false positive, because elevator switch can't happen until disk is added, and the splat can be avoided by switching to down_read_nested() in elevator_change(), which need to be nested too. So looks fine to use rwsem. Thanks, Ming
