[PATCH] nptl: Add backoff mechanism to spinlock loop

[Noah Goldstein]

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 :)


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