This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3 1/3] Tunables: Add tunables of spin count for pthread adaptive spin mutex
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Kemi Wang <kemi dot wang at intel dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Florian Weimer <fweimer at redhat dot com>, Rical Jason <rj at 2c3t dot io>, Carlos Donell <carlos at redhat dot com>, Glibc alpha <libc-alpha at sourceware dot org>
- Cc: nd at arm dot com, Dave Hansen <dave dot hansen at linux dot intel dot com>, Tim Chen <tim dot c dot chen at intel dot com>, Andi Kleen <andi dot kleen at intel dot com>, Ying Huang <ying dot huang at intel dot com>, Aaron Lu <aaron dot lu at intel dot com>, Lu Aubrey <aubrey dot li at intel dot com>
- Date: Thu, 7 Jun 2018 14:06:56 +0100
- Subject: Re: [PATCH v3 1/3] Tunables: Add tunables of spin count for pthread adaptive spin mutex
- Nodisclaimer: True
- References: <1527067354-13333-1-git-send-email-kemi.wang@intel.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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).