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

[Peter Zijlstra]

On Tue, Sep 15, 2026 at 06:47:17PM +0100, David Laight wrote:
> 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).

Then do all that in a separate patch.

This series as a whole is a giant trainwreck. The patches do too much
and say too little.