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: <CANDhNCrz=3Xp=bfydZycPgzr82YVHYk00LeaKSf9dQ5DA1Z5vA@mail.gmail.com>
Date: Thu, 11 Dec 2025 16:03:50 +0900
From: John Stultz <jstultz@...gle.com>
To: Bongkyu Kim <bongkyu7.kim@...sung.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
Subject: Re: [PATCH v3] locking/rwsem: Reintroduce reader optimistic spinning conditionally

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ