Re: [PATCH] locking/osq_lock: Ensure proper locking semantics for osq_lock/osq_unlock()

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Sep 14, 2026 at 10:30:12PM -0400, Waiman Long wrote:
> On 9/14/26 7:22 AM, Peter Zijlstra wrote:

> > > The "node->locked" read in osq_lock() was relaxed by commit 036cc30c6ba
> > > ("locking/osq: No need for load/acquire when acquire-polling") a while
> > > ago as the smp_load_acquire() loop was causing a performance hit due to
> > > the repeated acquire barriers in the loop and it argued that an earlier
> > > atomic_xchg() call could provide the needed barrier. That may not be
> > > enough especially if we have to loop for a while before the lock is
> > > released. Now with the new smp_cond_load_acquire() helper, only one
> > > acquire barrier is added at the end of the loop. So it shouldn't have
> > > the performance hit noted in that commit.

> > You need to substantiate this *should*.

> I don't have a good benchmark that can show any noticeable performance
> difference by adding an acquire barrier. My suspicion is that a repeating
> acquire barrier can be expensive depending on the actual processor used.
> Anyway the other osq_lock/osq_unlock() entry and exit points all have
> suitable barrier. I doubt adding one more acquire barrier will have a
> noticeable impact given that it is one-off at the end instead of a repeating
> one like the original osq_lock() code.

The obvious benchmark is the one that got used for 036cc30c6ba, no?