From: Peter Zijlstra <peterz@infradead.org>
To: Waiman Long <longman@redhat.com>
Cc: Peng Wang <peng_wang@linux.alibaba.com>,
mingo@redhat.com, will@kernel.org, boqun@kernel.org,
dbueso@suse.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] locking/rwsem: Remove reader optimistic lock stealing
Date: Fri, 22 May 2026 11:14:36 +0200 [thread overview]
Message-ID: <20260522091436.GT3102924@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20260522085513.GN3126523@noisy.programming.kicks-ass.net>
On Fri, May 22, 2026 at 10:55:13AM +0200, Peter Zijlstra wrote:
> On Thu, May 21, 2026 at 10:08:58PM -0400, Waiman Long wrote:
> > On 5/21/26 5:59 AM, Peng Wang wrote:
> > > Reader optimistic lock stealing, introduced by commit 1a728dff855a
> > > ("locking/rwsem: Enable reader optimistic lock stealing") and made more
> > > aggressive by commit 617f3ef95177 ("locking/rwsem: Remove reader
> > > optimistic spinning"), allows a reader entering the slowpath to bypass
> > > the wait queue and acquire the lock directly when WRITER_LOCKED and
> > > HANDOFF bits are not set.
> > >
> > > This causes severe writer starvation in workloads where readers hold
> > > the lock for extended periods, such as Direct I/O operations which
> > > hold inode->i_rwsem for the entire duration of iomap_dio_rw(). A
> > > common example is log-structured storage where one thread appends via
> > > DIO writes while another thread tails the log via DIO reads -- a
> > > pattern seen in database redo-log replay and shared-storage
> > > replication.
> >
> > It is generally assume that reader lock critical section is shorter than
> > that of writer. In this particular case, does the reader critical section
> > run longer than the writer's one?
>
> Well, that and writers are assumed to be rare. Reader-writer setups
> where writers are common or even dominant make little sense. And that
> seems to be exactly this. Then again, it isn't unreasonable to expect it
> to not perform significantly worse than an exclusive lock.
>
> > Reader lock stealing should only happen if the previous lock owner is a
> > writer. So readers and writer should at most alternately own the lock if
> > there are many readers waiting. Of course, if a reader own the lock, it will
> > wake up the remaining readers in the wait queue.
>
> Anyway, IIRC I've mentioned phase change locks many times before. And
> what we have here is an asymmetric phase change. The timeout causes a
> change to writers, but any one writer completing then switches back to
> reader dominance.
>
> Perhaps look at evening out the phase change. Retain the 'no-steal'
> phase for an equal duration.
>
> Also, 4ms is an eternity, that might need tweaking too.
Also, perhaps reduce MAX_READERS_WAKEUP when in the 'writer' phase of
things.
next prev parent reply other threads:[~2026-05-22 9:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-21 9:59 [PATCH] locking/rwsem: Remove reader optimistic lock stealing Peng Wang
2026-05-22 2:08 ` Waiman Long
2026-05-22 3:33 ` Peng Wang
2026-05-22 8:55 ` Peter Zijlstra
2026-05-22 9:14 ` Peter Zijlstra [this message]
2026-05-22 10:06 ` Peng Wang
2026-06-04 14:14 ` [RFC PATCH v2] locking/rwsem: Block reader stealing during writer phase Peng Wang
2026-05-31 7:27 ` [PATCH] locking/rwsem: Remove reader optimistic lock stealing kernel test robot
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=20260522091436.GT3102924@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=boqun@kernel.org \
--cc=dbueso@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peng_wang@linux.alibaba.com \
--cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox