This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 1/3] Mutex: Accelerate lock acquisition by queuing spinner
- From: kemi <kemi dot wang at intel dot com>
- To: Carlos <carlos at redhat dot com>, Glibc alpha <libc-alpha at sourceware dot org>
- Date: Fri, 21 Dec 2018 18:17:55 +0800
- Subject: Re: [PATCH v2 1/3] Mutex: Accelerate lock acquisition by queuing spinner
- References: <1545286557-20901-1-git-send-email-kemi.wang@intel.com>
Hi, Dear maintainers
I hope this patchset can catch up 2.29 release cycle, could you help
to get it reviewed. If any question, I will resolve it ASAP. Thanks
On 2018/12/20 下午2:15, Kemi Wang wrote:
> Adaptive mutex indicates the semantic of spinning for a while before
> calling into the kernel to block. Thus, the lock of adaptive mutex could be
> acquired via immediate getting, spinning getting or waking up.
>
> Currently, the spin-waiting algorithm of adaptive mutex is for each
> processor to repeatedly execute an test_and_set instruction until either
> the maximum spin count is reached or the lock is acquired. However, the
> lock performance via spinning getting will degrade significantly as the
> number of spinning processors increases. Two factors at least cause this
> degradation[1]. First, in order to release the lock, the lock holder has to
> contend with spinning processors for exclusive access of lock cache line.
> (E.g. "lock; decl 0%" of lll_unlock() in
> sysdeps/unix/sysv/linux/x86_64/lowlevellock.h for pthread_mutex_unlock()).
> For most multiprocessor architectures, it has to wait behind those
> test_and_set instructions from spinning processors.
> Furthermore, on these invalidation-based cache coherency system,
> test_and_set instruction will trigger a "read-for-ownership" request for
> exclusive access to the lock cache line, it will potentially slow the
> access of other locations(shares the cache line with the lock at least) by
> the lock holder.
>