Re: [PATCH v4 next 3/9] locking/osq_lock: Set prev_cpu=0 instead of locked=1

[David Laight]

On Tue, 15 Sep 2026 16:01:52 +0200
Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:

> On Tue, Sep 15, 2026 at 02:55:13PM +0100, David Laight wrote:
> 
> > > That comment *should* obviously have been here. Also, I would *much*
> > > rather have this store at the top, next to node->next = NULL; That is
> > > much saner.  
> > 
> > 
> > Part of the original reason I started these patches was to remove
> > the writes to the current cpu's 'node' in the fast path acquire.
> > That completely saves reading the cache line.
> > It also means the initial xchg need only have acquire semantics.  
> 
> That makes no sense... you *have* to write node->prev_cpu, and since you
> get to have the line dirty for that, a few more stores to the same line
> are 'free', no?

But you don't always have to do that write.
If the lock isn't held then you only have to update osq_lock->tail
to contain the current cpu number.
The per-cpu data remains zero - the same as when unlocked (and initialised).

David

> 
> Trying to make the code keep invariants like that also makes it
> needlessly convoluted.
> 
> If you need a store -- and you do, then you might as well write the
> whole thing.
> 
> And if you think it makes a difference, your changelogs completely lack
> any factual data to that effect. That is, there are no numbers. And
> without numbers, we're just not doing this.