The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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.

  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