[PATCH] nptl: Add backoff mechanism to spinlock loop

Noah Goldstein goldstein.w.n@gmail.com
Fri Mar 25 03:42:12 GMT 2022


On Thu, Mar 24, 2022 at 10:24 PM Guo, Wangyang <wangyang.guo@intel.com> 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?



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


More information about the Libc-alpha mailing list