RE: [PATCH v3 1/3] Tunables: Add tunables of spin count for pthread adaptive spin mutex

["Wang, Kemi" <kemi dot wang at intel dot com>]

> i'm not against this tunable, but do ppl use PTHREAD_MUTEX_ADAPTIVE_NP in practice?

Absolutely!  Our customers complained to us that  adaptive mutex does not run well on Intel Skylake platform.
I am not a fan of adding code that no one cares. The tuning work is on going with kinds of benchmarks I can get.
If we can find a suitable threshold of spin count to fit most cases in future, I don't mind to remove this tunable. 
But now, it indeed need.

> it's a non-standard extension, if the normal mutex is not good enough that should be fixed (e.g. it should do some spinning on SMP systems if that's useful in general, the futex syscall overhead is way bigger than a few atomic loads).

That is what adaptive mutex does now, spinning for a while before going to block. 
If the adaptive mutex is optimized good enough, maybe we should make it as a default option (e.g. the mutex used in kernel spins for a while before sleep, and it also use mcs lock to queue spinners)

-----Original Message-----
From: libc-alpha-owner@sourceware.org [mailto:libc-alpha-owner@sourceware.org] On Behalf Of Szabolcs Nagy
Sent: Thursday, June 7, 2018 9:07 PM
To: Wang, Kemi <kemi.wang@intel.com>; Adhemerval Zanella <adhemerval.zanella@linaro.org>; Florian Weimer <fweimer@redhat.com>; Rical Jason <rj@2c3t.io>; Carlos Donell <carlos@redhat.com>; Glibc alpha <libc-alpha@sourceware.org>
Cc: nd@arm.com; Dave Hansen <dave.hansen@linux.intel.com>; Chen, Tim C <tim.c.chen@intel.com>; Kleen, Andi <andi.kleen@intel.com>; Huang, Ying <ying.huang@intel.com>; Lu, Aaron <aaron.lu@intel.com>; Li, Aubrey <aubrey.li@intel.com>
Subject: Re: [PATCH v3 1/3] Tunables: Add tunables of spin count for pthread adaptive spin mutex

On 23/05/18 10:22, Kemi Wang wrote:
> This patch does not have any functionality change, we only provide a 
> spin count tunes for pthread adaptive spin mutex. The tunable 
> glibc.mutex.spin_count tunes can be used by system administrator to 
> squeeze system performance according to different hardware 
> capabilities and workload characteristics.
> 
> The maximum value of spin count is limited to 30000 to avoid the 
> overflow of mutex->__data.__spins variable with the possible type of 
> short in pthread_mutex_lock ().
> 
> The default value of spin count is set to 100 with the reference to 
> the previous number of times of spinning via trylock. This value would 
> be architecture-specific and can be tuned with kinds of benchmarks to 
> fit most cases in future.
> 

i'm not against this tunable, but do ppl use PTHREAD_MUTEX_ADAPTIVE_NP in practice?

it's a non-standard extension, if the normal mutex is not good enough that should be fixed (e.g. it should do some spinning on SMP systems if that's useful in general, the futex syscall overhead is way bigger than a few atomic loads).