linux-kernel - Re: [PATCH v3] locking/rwsem: Reintroduce reader optimistic spinning conditionally

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aTy4umirJ8pcHy+V@KORCO181097.samsungds.net>
Date: Sat, 13 Dec 2025 09:52:10 +0900
From: Bongkyu Kim <bongkyu7.kim@...sung.com>
To: John Stultz <jstultz@...gle.com>
Cc: peterz@...radead.org, mingo@...hat.com, will@...nel.org,
	longman@...hat.com, boqun.feng@...il.com, corbet@....net,
	gregkh@...uxfoundation.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, bongkyu7.kim@...sung.com
Subject: Re: [PATCH v3] locking/rwsem: Reintroduce reader optimistic
 spinning conditionally

Hi John,

This patch did not move forward because there were no further replies here.

In addition, the app launch time issue I was experiencing was resolved by
the “Per VMA lock” patch, so the reader optimistic spinning patch is no longer
necessary for app launch time.

Thanks,
Bongkyu

On Thu, Dec 11, 2025 at 04:03:50PM +0900, John Stultz wrote:
> On Mon, Apr 29, 2024 at 8:08 PM Bongkyu Kim <bongkyu7.kim@...sung.com> wrote:
> > On 4/6/24 17:11, Bongkyu Kim wrote:
> > > Reader optimistic spinning is helpful when the reader critical section
> > > is short and there aren't that many readers around. It also improves
> > > the chance that a reader can get the lock as writer optimistic spinning
> > > disproportionally favors writers much more than readers.
> > >
> > > Since commit 617f3ef95177 ("locking/rwsem: Remove reader optimistic
> > > spinning"), reader optimistic spinning was taken out is because of
> > > reader fragmentation especially now that we essentially wake up all the
> > > readers all at once when it is reader's turn to take the read lock.
> > >
> > > But, on smaller systems with just a few CPU cores, reader optimistic
> > > spinning may help performance. So, reintroduce reader optimistic
> > > spinning and enable it when the number of cores in the system <= the
> > > threshold (default set to 8 cores). This threshold can be changed by
> > > "rwsem.rspin_maxcpus" commandline.
> > >
> > > The simple heuristic of skipping optimistic spinning if the lock is
> > > reader owned is kept, reader optimistic spinning won't affect handoff
> > > handling which requires that an unlocker see the lock will be free and
> > > wake up the head of the wait queue.
> ...
> > Hi Longman,
> >
> > I made a new patch as you suggested.
> > I would appreciate if if you could review it.
> 
> Hey Bongkyu,
>   I just wanted to follow up here to see if this patch was abandoned
> or if further discussion elsewhere resulted in it not being
> resubmitted?
> 
> thanks
> -john
>