[PATCH] nptl: Add backoff mechanism to spinlock loop

[Guo, Wangyang]

> On Thu, Mar 24, 2022 at 11:32 PM Guo, Wangyang <wangyang.guo@intel.com> wrote:
> >
> > Noah Goldstein wrote:
> > > > >> +                 atomic_spin_nop ();
> > > > >> +             while (--spin_count > 0);
> > > > >> +             /* Binary exponential backoff, prepare for next loop.  */
> > > > >> +             exp_backoff <<= 1;
> > > > >>             }
> > > > >>           while (LLL_MUTEX_READ_LOCK (mutex) != 0
> > > > >Does this load not already prevent against the 'CAS storm'?
> > > > This just prevent CAS in a long held lock.
> > > > But if multiple threads waiting for lock at the same time, suppose 
> > > > many of them are going to read lock state, once the lock owner release the lock at this point, those waiter threads will be convinced lock is unlocked.
> > > > The next step, they will all do try lock at the same time. Backoff is introduced to solve this problem.
> > >
> > > The loop isn't spinning on CAS failure which is typically where you see the poor performance.
> > > I get that there can still be some contention on the CAS, but shouldn't the read check limit the evict ping-ponging?
> >
> > Yes, read check can help.
> > But in a very high contention case, it becomes more easier to meet the above problem that needs backoff.
> Do we need both then?
> But made a quick benchmark to test this out and your right, using the lock for a tiny critical section at least (incrementing an int) see less failed CAS attempts w/ this patch and better performance :)

In theory, the read-check still works in a long held lock, but will have extra overhead if lock can be acquired immediately.
From my testing, without read-check has a better performance.

> > > >
> > > > >>                  || LLL_MUTEX_TRYLOCK (mutex) != 0);
> > > >