glibc/sysdeps/unix/sysv/linux/x86/elision-conf.c

137 lines
4.7 KiB
C
Raw Normal View History

Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
/* elision-conf.c: Lock elision tunable parameters.
Copyright (C) 2013-2020 Free Software Foundation, Inc.
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, see
Prefer https to http for gnu.org and fsf.org URLs Also, change sources.redhat.com to sourceware.org. This patch was automatically generated by running the following shell script, which uses GNU sed, and which avoids modifying files imported from upstream: sed -ri ' s,(http|ftp)(://(.*\.)?(gnu|fsf|sourceware)\.org($|[^.]|\.[^a-z])),https\2,g s,(http|ftp)(://(.*\.)?)sources\.redhat\.com($|[^.]|\.[^a-z]),https\2sourceware.org\4,g ' \ $(find $(git ls-files) -prune -type f \ ! -name '*.po' \ ! -name 'ChangeLog*' \ ! -path COPYING ! -path COPYING.LIB \ ! -path manual/fdl-1.3.texi ! -path manual/lgpl-2.1.texi \ ! -path manual/texinfo.tex ! -path scripts/config.guess \ ! -path scripts/config.sub ! -path scripts/install-sh \ ! -path scripts/mkinstalldirs ! -path scripts/move-if-change \ ! -path INSTALL ! -path locale/programs/charmap-kw.h \ ! -path po/libc.pot ! -path sysdeps/gnu/errlist.c \ ! '(' -name configure \ -execdir test -f configure.ac -o -f configure.in ';' ')' \ ! '(' -name preconfigure \ -execdir test -f preconfigure.ac ';' ')' \ -print) and then by running 'make dist-prepare' to regenerate files built from the altered files, and then executing the following to cleanup: chmod a+x sysdeps/unix/sysv/linux/riscv/configure # Omit irrelevant whitespace and comment-only changes, # perhaps from a slightly-different Autoconf version. git checkout -f \ sysdeps/csky/configure \ sysdeps/hppa/configure \ sysdeps/riscv/configure \ sysdeps/unix/sysv/linux/csky/configure # Omit changes that caused a pre-commit check to fail like this: # remote: *** error: sysdeps/powerpc/powerpc64/ppc-mcount.S: trailing lines git checkout -f \ sysdeps/powerpc/powerpc64/ppc-mcount.S \ sysdeps/unix/sysv/linux/s390/s390-64/syscall.S # Omit change that caused a pre-commit check to fail like this: # remote: *** error: sysdeps/sparc/sparc64/multiarch/memcpy-ultra3.S: last line does not end in newline git checkout -f sysdeps/sparc/sparc64/multiarch/memcpy-ultra3.S
2019-09-07 05:40:42 +00:00
<https://www.gnu.org/licenses/>. */
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
#include "config.h"
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
#include <pthreadP.h>
#include <init-arch.h>
#include <elision-conf.h>
#include <unistd.h>
Add elision tunables This patch adds several new tunables to control the behavior of elision on supported platforms[1]. Since elision now depends on tunables, we should always *compile* with elision enabled, and leave the code disabled, but available for runtime selection. This gives us *much* better compile-time testing of the existing code to avoid bit-rot[2]. Tested on ppc, ppc64, ppc64le, s390x and x86_64. [1] This part of the patch was initially proposed by Paul Murphy but was "staled" because the framework have changed since the patch was originally proposed: https://patchwork.sourceware.org/patch/10342/ [2] This part of the patch was inititally proposed as a RFC by Carlos O'Donnell. Make sense to me integrate this on the patch: https://sourceware.org/ml/libc-alpha/2017-05/msg00335.html * elf/dl-tunables.list: Add elision parameters. * manual/tunables.texi: Add entries about elision tunable. * sysdeps/unix/sysv/linux/powerpc/elision-conf.c: Add callback functions to dynamically enable/disable elision. Add multiple callbacks functions to set elision parameters. Deleted __libc_enable_secure check. * sysdeps/unix/sysv/linux/s390/elision-conf.c: Likewise. * sysdeps/unix/sysv/linux/x86/elision-conf.c: Likewise. * configure: Regenerated. * configure.ac: Option enable_lock_elision was deleted. * config.h.in: ENABLE_LOCK_ELISION flag was deleted. * config.make.in: Remove references to enable_lock_elision. * manual/install.texi: Elision configure option was removed. * INSTALL: Regenerated to remove enable_lock_elision. * nptl/Makefile: Disable elision so it can verify error case for destroying a mutex. * sysdeps/powerpc/nptl/elide.h: Cleanup ENABLE_LOCK_ELISION check. Deleted macros for the case when ENABLE_LOCK_ELISION was not defined. * sysdeps/s390/configure: Regenerated. * sysdeps/s390/configure.ac: Remove references to enable_lock_elision.. * nptl/tst-mutex8.c: Deleted all #ifndef ENABLE_LOCK_ELISION from the test. * sysdeps/powerpc/powerpc32/sysdep.h: Deleted all ENABLE_LOCK_ELISION checks. * sysdeps/powerpc/powerpc64/sysdep.h: Likewise. * sysdeps/powerpc/sysdep.h: Likewise. * sysdeps/s390/nptl/bits/pthreadtypes-arch.h: Likewise. * sysdeps/unix/sysv/linux/powerpc/force-elision.h: Likewise. * sysdeps/unix/sysv/linux/s390/elision-conf.h: Likewise. * sysdeps/unix/sysv/linux/s390/force-elision.h: Likewise. * sysdeps/unix/sysv/linux/s390/lowlevellock.h: Likewise. * sysdeps/unix/sysv/linux/s390/Makefile: Remove references to enable-lock-elision. Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
2017-12-05 16:24:14 +00:00
#if HAVE_TUNABLES
# define TUNABLE_NAMESPACE elision
#endif
#include <elf/dl-tunables.h>
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
/* Reasonable initial tuning values, may be revised in the future.
This is a conservative initial value. */
struct elision_config __elision_aconf =
{
/* How often to not attempt to use elision if a transaction aborted
because the lock is already acquired. Expressed in number of lock
acquisition attempts. */
.skip_lock_busy = 3,
/* How often to not attempt to use elision if a transaction aborted due
to reasons other than other threads' memory accesses. Expressed in
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
number of lock acquisition attempts. */
.skip_lock_internal_abort = 3,
/* How often we retry using elision if there is chance for the transaction
to finish execution (e.g., it wasn't aborted due to the lock being
already acquired. */
.retry_try_xbegin = 3,
/* Same as SKIP_LOCK_INTERNAL_ABORT but for trylock. */
.skip_trylock_internal_abort = 3,
};
/* Force elision for all new locks. This is used to decide whether existing
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
DEFAULT locks should be automatically upgraded to elision in
pthread_mutex_lock(). Disabled for suid programs. Only used when elision
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
is available. */
Add elision tunables This patch adds several new tunables to control the behavior of elision on supported platforms[1]. Since elision now depends on tunables, we should always *compile* with elision enabled, and leave the code disabled, but available for runtime selection. This gives us *much* better compile-time testing of the existing code to avoid bit-rot[2]. Tested on ppc, ppc64, ppc64le, s390x and x86_64. [1] This part of the patch was initially proposed by Paul Murphy but was "staled" because the framework have changed since the patch was originally proposed: https://patchwork.sourceware.org/patch/10342/ [2] This part of the patch was inititally proposed as a RFC by Carlos O'Donnell. Make sense to me integrate this on the patch: https://sourceware.org/ml/libc-alpha/2017-05/msg00335.html * elf/dl-tunables.list: Add elision parameters. * manual/tunables.texi: Add entries about elision tunable. * sysdeps/unix/sysv/linux/powerpc/elision-conf.c: Add callback functions to dynamically enable/disable elision. Add multiple callbacks functions to set elision parameters. Deleted __libc_enable_secure check. * sysdeps/unix/sysv/linux/s390/elision-conf.c: Likewise. * sysdeps/unix/sysv/linux/x86/elision-conf.c: Likewise. * configure: Regenerated. * configure.ac: Option enable_lock_elision was deleted. * config.h.in: ENABLE_LOCK_ELISION flag was deleted. * config.make.in: Remove references to enable_lock_elision. * manual/install.texi: Elision configure option was removed. * INSTALL: Regenerated to remove enable_lock_elision. * nptl/Makefile: Disable elision so it can verify error case for destroying a mutex. * sysdeps/powerpc/nptl/elide.h: Cleanup ENABLE_LOCK_ELISION check. Deleted macros for the case when ENABLE_LOCK_ELISION was not defined. * sysdeps/s390/configure: Regenerated. * sysdeps/s390/configure.ac: Remove references to enable_lock_elision.. * nptl/tst-mutex8.c: Deleted all #ifndef ENABLE_LOCK_ELISION from the test. * sysdeps/powerpc/powerpc32/sysdep.h: Deleted all ENABLE_LOCK_ELISION checks. * sysdeps/powerpc/powerpc64/sysdep.h: Likewise. * sysdeps/powerpc/sysdep.h: Likewise. * sysdeps/s390/nptl/bits/pthreadtypes-arch.h: Likewise. * sysdeps/unix/sysv/linux/powerpc/force-elision.h: Likewise. * sysdeps/unix/sysv/linux/s390/elision-conf.h: Likewise. * sysdeps/unix/sysv/linux/s390/force-elision.h: Likewise. * sysdeps/unix/sysv/linux/s390/lowlevellock.h: Likewise. * sysdeps/unix/sysv/linux/s390/Makefile: Remove references to enable-lock-elision. Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
2017-12-05 16:24:14 +00:00
int __pthread_force_elision attribute_hidden = 0;
#if HAVE_TUNABLES
Avoid "inline" after return type in function definitions. One group of warnings seen with -Wextra is warnings for static or inline not at the start of a declaration (-Wold-style-declaration). This patch fixes various such cases for inline, ensuring it comes at the start of the declaration (after any static). A common case of the fix is "static inline <type> __always_inline"; the definition of __always_inline starts with __inline, so the natural change is to "static __always_inline <type>". Other cases of the warning may be harder to fix (one pattern is a function definition that gets rewritten to be static by an including file, "#define funcname static wrapped_funcname" or similar), but it seems worth fixing these cases with inline anyway. Tested for x86_64. * elf/dl-load.h (_dl_postprocess_loadcmd): Use __always_inline before return type, without separate inline. * elf/dl-tunables.c (maybe_enable_malloc_check): Likewise. * elf/dl-tunables.h (tunable_is_name): Likewise. * malloc/malloc.c (do_set_trim_threshold): Likewise. (do_set_top_pad): Likewise. (do_set_mmap_threshold): Likewise. (do_set_mmaps_max): Likewise. (do_set_mallopt_check): Likewise. (do_set_perturb_byte): Likewise. (do_set_arena_test): Likewise. (do_set_arena_max): Likewise. (do_set_tcache_max): Likewise. (do_set_tcache_count): Likewise. (do_set_tcache_unsorted_limit): Likewise. * nis/nis_subr.c (count_dots): Likewise. * nptl/allocatestack.c (advise_stack_range): Likewise. * sysdeps/ieee754/dbl-64/s_sin.c (do_cos): Likewise. (do_sin): Likewise. (reduce_sincos): Likewise. (do_sincos): Likewise. * sysdeps/unix/sysv/linux/x86/elision-conf.c (do_set_elision_enable): Likewise. (TUNABLE_CALLBACK_FNDECL): Likewise.
2019-02-06 17:16:43 +00:00
static __always_inline void
Add elision tunables This patch adds several new tunables to control the behavior of elision on supported platforms[1]. Since elision now depends on tunables, we should always *compile* with elision enabled, and leave the code disabled, but available for runtime selection. This gives us *much* better compile-time testing of the existing code to avoid bit-rot[2]. Tested on ppc, ppc64, ppc64le, s390x and x86_64. [1] This part of the patch was initially proposed by Paul Murphy but was "staled" because the framework have changed since the patch was originally proposed: https://patchwork.sourceware.org/patch/10342/ [2] This part of the patch was inititally proposed as a RFC by Carlos O'Donnell. Make sense to me integrate this on the patch: https://sourceware.org/ml/libc-alpha/2017-05/msg00335.html * elf/dl-tunables.list: Add elision parameters. * manual/tunables.texi: Add entries about elision tunable. * sysdeps/unix/sysv/linux/powerpc/elision-conf.c: Add callback functions to dynamically enable/disable elision. Add multiple callbacks functions to set elision parameters. Deleted __libc_enable_secure check. * sysdeps/unix/sysv/linux/s390/elision-conf.c: Likewise. * sysdeps/unix/sysv/linux/x86/elision-conf.c: Likewise. * configure: Regenerated. * configure.ac: Option enable_lock_elision was deleted. * config.h.in: ENABLE_LOCK_ELISION flag was deleted. * config.make.in: Remove references to enable_lock_elision. * manual/install.texi: Elision configure option was removed. * INSTALL: Regenerated to remove enable_lock_elision. * nptl/Makefile: Disable elision so it can verify error case for destroying a mutex. * sysdeps/powerpc/nptl/elide.h: Cleanup ENABLE_LOCK_ELISION check. Deleted macros for the case when ENABLE_LOCK_ELISION was not defined. * sysdeps/s390/configure: Regenerated. * sysdeps/s390/configure.ac: Remove references to enable_lock_elision.. * nptl/tst-mutex8.c: Deleted all #ifndef ENABLE_LOCK_ELISION from the test. * sysdeps/powerpc/powerpc32/sysdep.h: Deleted all ENABLE_LOCK_ELISION checks. * sysdeps/powerpc/powerpc64/sysdep.h: Likewise. * sysdeps/powerpc/sysdep.h: Likewise. * sysdeps/s390/nptl/bits/pthreadtypes-arch.h: Likewise. * sysdeps/unix/sysv/linux/powerpc/force-elision.h: Likewise. * sysdeps/unix/sysv/linux/s390/elision-conf.h: Likewise. * sysdeps/unix/sysv/linux/s390/force-elision.h: Likewise. * sysdeps/unix/sysv/linux/s390/lowlevellock.h: Likewise. * sysdeps/unix/sysv/linux/s390/Makefile: Remove references to enable-lock-elision. Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
2017-12-05 16:24:14 +00:00
do_set_elision_enable (int32_t elision_enable)
{
/* Enable elision if it's avaliable in hardware. It's not necessary to check
if __libc_enable_secure isn't enabled since elision_enable will be set
according to the default, which is disabled. */
if (elision_enable == 1)
__pthread_force_elision = CPU_FEATURE_USABLE (RTM) ? 1 : 0;
Add elision tunables This patch adds several new tunables to control the behavior of elision on supported platforms[1]. Since elision now depends on tunables, we should always *compile* with elision enabled, and leave the code disabled, but available for runtime selection. This gives us *much* better compile-time testing of the existing code to avoid bit-rot[2]. Tested on ppc, ppc64, ppc64le, s390x and x86_64. [1] This part of the patch was initially proposed by Paul Murphy but was "staled" because the framework have changed since the patch was originally proposed: https://patchwork.sourceware.org/patch/10342/ [2] This part of the patch was inititally proposed as a RFC by Carlos O'Donnell. Make sense to me integrate this on the patch: https://sourceware.org/ml/libc-alpha/2017-05/msg00335.html * elf/dl-tunables.list: Add elision parameters. * manual/tunables.texi: Add entries about elision tunable. * sysdeps/unix/sysv/linux/powerpc/elision-conf.c: Add callback functions to dynamically enable/disable elision. Add multiple callbacks functions to set elision parameters. Deleted __libc_enable_secure check. * sysdeps/unix/sysv/linux/s390/elision-conf.c: Likewise. * sysdeps/unix/sysv/linux/x86/elision-conf.c: Likewise. * configure: Regenerated. * configure.ac: Option enable_lock_elision was deleted. * config.h.in: ENABLE_LOCK_ELISION flag was deleted. * config.make.in: Remove references to enable_lock_elision. * manual/install.texi: Elision configure option was removed. * INSTALL: Regenerated to remove enable_lock_elision. * nptl/Makefile: Disable elision so it can verify error case for destroying a mutex. * sysdeps/powerpc/nptl/elide.h: Cleanup ENABLE_LOCK_ELISION check. Deleted macros for the case when ENABLE_LOCK_ELISION was not defined. * sysdeps/s390/configure: Regenerated. * sysdeps/s390/configure.ac: Remove references to enable_lock_elision.. * nptl/tst-mutex8.c: Deleted all #ifndef ENABLE_LOCK_ELISION from the test. * sysdeps/powerpc/powerpc32/sysdep.h: Deleted all ENABLE_LOCK_ELISION checks. * sysdeps/powerpc/powerpc64/sysdep.h: Likewise. * sysdeps/powerpc/sysdep.h: Likewise. * sysdeps/s390/nptl/bits/pthreadtypes-arch.h: Likewise. * sysdeps/unix/sysv/linux/powerpc/force-elision.h: Likewise. * sysdeps/unix/sysv/linux/s390/elision-conf.h: Likewise. * sysdeps/unix/sysv/linux/s390/force-elision.h: Likewise. * sysdeps/unix/sysv/linux/s390/lowlevellock.h: Likewise. * sysdeps/unix/sysv/linux/s390/Makefile: Remove references to enable-lock-elision. Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
2017-12-05 16:24:14 +00:00
}
/* The pthread->elision_enable tunable is 0 or 1 indicating that elision
should be disabled or enabled respectively. The feature will only be used
if it's supported by the hardware. */
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
Add elision tunables This patch adds several new tunables to control the behavior of elision on supported platforms[1]. Since elision now depends on tunables, we should always *compile* with elision enabled, and leave the code disabled, but available for runtime selection. This gives us *much* better compile-time testing of the existing code to avoid bit-rot[2]. Tested on ppc, ppc64, ppc64le, s390x and x86_64. [1] This part of the patch was initially proposed by Paul Murphy but was "staled" because the framework have changed since the patch was originally proposed: https://patchwork.sourceware.org/patch/10342/ [2] This part of the patch was inititally proposed as a RFC by Carlos O'Donnell. Make sense to me integrate this on the patch: https://sourceware.org/ml/libc-alpha/2017-05/msg00335.html * elf/dl-tunables.list: Add elision parameters. * manual/tunables.texi: Add entries about elision tunable. * sysdeps/unix/sysv/linux/powerpc/elision-conf.c: Add callback functions to dynamically enable/disable elision. Add multiple callbacks functions to set elision parameters. Deleted __libc_enable_secure check. * sysdeps/unix/sysv/linux/s390/elision-conf.c: Likewise. * sysdeps/unix/sysv/linux/x86/elision-conf.c: Likewise. * configure: Regenerated. * configure.ac: Option enable_lock_elision was deleted. * config.h.in: ENABLE_LOCK_ELISION flag was deleted. * config.make.in: Remove references to enable_lock_elision. * manual/install.texi: Elision configure option was removed. * INSTALL: Regenerated to remove enable_lock_elision. * nptl/Makefile: Disable elision so it can verify error case for destroying a mutex. * sysdeps/powerpc/nptl/elide.h: Cleanup ENABLE_LOCK_ELISION check. Deleted macros for the case when ENABLE_LOCK_ELISION was not defined. * sysdeps/s390/configure: Regenerated. * sysdeps/s390/configure.ac: Remove references to enable_lock_elision.. * nptl/tst-mutex8.c: Deleted all #ifndef ENABLE_LOCK_ELISION from the test. * sysdeps/powerpc/powerpc32/sysdep.h: Deleted all ENABLE_LOCK_ELISION checks. * sysdeps/powerpc/powerpc64/sysdep.h: Likewise. * sysdeps/powerpc/sysdep.h: Likewise. * sysdeps/s390/nptl/bits/pthreadtypes-arch.h: Likewise. * sysdeps/unix/sysv/linux/powerpc/force-elision.h: Likewise. * sysdeps/unix/sysv/linux/s390/elision-conf.h: Likewise. * sysdeps/unix/sysv/linux/s390/force-elision.h: Likewise. * sysdeps/unix/sysv/linux/s390/lowlevellock.h: Likewise. * sysdeps/unix/sysv/linux/s390/Makefile: Remove references to enable-lock-elision. Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
2017-12-05 16:24:14 +00:00
void
TUNABLE_CALLBACK (set_elision_enable) (tunable_val_t *valp)
{
int32_t elision_enable = (int32_t) valp->numval;
do_set_elision_enable (elision_enable);
}
#define TUNABLE_CALLBACK_FNDECL(__name, __type) \
Avoid "inline" after return type in function definitions. One group of warnings seen with -Wextra is warnings for static or inline not at the start of a declaration (-Wold-style-declaration). This patch fixes various such cases for inline, ensuring it comes at the start of the declaration (after any static). A common case of the fix is "static inline <type> __always_inline"; the definition of __always_inline starts with __inline, so the natural change is to "static __always_inline <type>". Other cases of the warning may be harder to fix (one pattern is a function definition that gets rewritten to be static by an including file, "#define funcname static wrapped_funcname" or similar), but it seems worth fixing these cases with inline anyway. Tested for x86_64. * elf/dl-load.h (_dl_postprocess_loadcmd): Use __always_inline before return type, without separate inline. * elf/dl-tunables.c (maybe_enable_malloc_check): Likewise. * elf/dl-tunables.h (tunable_is_name): Likewise. * malloc/malloc.c (do_set_trim_threshold): Likewise. (do_set_top_pad): Likewise. (do_set_mmap_threshold): Likewise. (do_set_mmaps_max): Likewise. (do_set_mallopt_check): Likewise. (do_set_perturb_byte): Likewise. (do_set_arena_test): Likewise. (do_set_arena_max): Likewise. (do_set_tcache_max): Likewise. (do_set_tcache_count): Likewise. (do_set_tcache_unsorted_limit): Likewise. * nis/nis_subr.c (count_dots): Likewise. * nptl/allocatestack.c (advise_stack_range): Likewise. * sysdeps/ieee754/dbl-64/s_sin.c (do_cos): Likewise. (do_sin): Likewise. (reduce_sincos): Likewise. (do_sincos): Likewise. * sysdeps/unix/sysv/linux/x86/elision-conf.c (do_set_elision_enable): Likewise. (TUNABLE_CALLBACK_FNDECL): Likewise.
2019-02-06 17:16:43 +00:00
static __always_inline void \
Add elision tunables This patch adds several new tunables to control the behavior of elision on supported platforms[1]. Since elision now depends on tunables, we should always *compile* with elision enabled, and leave the code disabled, but available for runtime selection. This gives us *much* better compile-time testing of the existing code to avoid bit-rot[2]. Tested on ppc, ppc64, ppc64le, s390x and x86_64. [1] This part of the patch was initially proposed by Paul Murphy but was "staled" because the framework have changed since the patch was originally proposed: https://patchwork.sourceware.org/patch/10342/ [2] This part of the patch was inititally proposed as a RFC by Carlos O'Donnell. Make sense to me integrate this on the patch: https://sourceware.org/ml/libc-alpha/2017-05/msg00335.html * elf/dl-tunables.list: Add elision parameters. * manual/tunables.texi: Add entries about elision tunable. * sysdeps/unix/sysv/linux/powerpc/elision-conf.c: Add callback functions to dynamically enable/disable elision. Add multiple callbacks functions to set elision parameters. Deleted __libc_enable_secure check. * sysdeps/unix/sysv/linux/s390/elision-conf.c: Likewise. * sysdeps/unix/sysv/linux/x86/elision-conf.c: Likewise. * configure: Regenerated. * configure.ac: Option enable_lock_elision was deleted. * config.h.in: ENABLE_LOCK_ELISION flag was deleted. * config.make.in: Remove references to enable_lock_elision. * manual/install.texi: Elision configure option was removed. * INSTALL: Regenerated to remove enable_lock_elision. * nptl/Makefile: Disable elision so it can verify error case for destroying a mutex. * sysdeps/powerpc/nptl/elide.h: Cleanup ENABLE_LOCK_ELISION check. Deleted macros for the case when ENABLE_LOCK_ELISION was not defined. * sysdeps/s390/configure: Regenerated. * sysdeps/s390/configure.ac: Remove references to enable_lock_elision.. * nptl/tst-mutex8.c: Deleted all #ifndef ENABLE_LOCK_ELISION from the test. * sysdeps/powerpc/powerpc32/sysdep.h: Deleted all ENABLE_LOCK_ELISION checks. * sysdeps/powerpc/powerpc64/sysdep.h: Likewise. * sysdeps/powerpc/sysdep.h: Likewise. * sysdeps/s390/nptl/bits/pthreadtypes-arch.h: Likewise. * sysdeps/unix/sysv/linux/powerpc/force-elision.h: Likewise. * sysdeps/unix/sysv/linux/s390/elision-conf.h: Likewise. * sysdeps/unix/sysv/linux/s390/force-elision.h: Likewise. * sysdeps/unix/sysv/linux/s390/lowlevellock.h: Likewise. * sysdeps/unix/sysv/linux/s390/Makefile: Remove references to enable-lock-elision. Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
2017-12-05 16:24:14 +00:00
do_set_elision_ ## __name (__type value) \
{ \
__elision_aconf.__name = value; \
} \
void \
TUNABLE_CALLBACK (set_elision_ ## __name) (tunable_val_t *valp) \
{ \
__type value = (__type) (valp)->numval; \
do_set_elision_ ## __name (value); \
}
TUNABLE_CALLBACK_FNDECL (skip_lock_busy, int32_t);
TUNABLE_CALLBACK_FNDECL (skip_lock_internal_abort, int32_t);
TUNABLE_CALLBACK_FNDECL (retry_try_xbegin, int32_t);
TUNABLE_CALLBACK_FNDECL (skip_trylock_internal_abort, int32_t);
#endif
/* Initialize elision. */
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
static void
elision_init (int argc __attribute__ ((unused)),
char **argv __attribute__ ((unused)),
char **environ)
{
Add elision tunables This patch adds several new tunables to control the behavior of elision on supported platforms[1]. Since elision now depends on tunables, we should always *compile* with elision enabled, and leave the code disabled, but available for runtime selection. This gives us *much* better compile-time testing of the existing code to avoid bit-rot[2]. Tested on ppc, ppc64, ppc64le, s390x and x86_64. [1] This part of the patch was initially proposed by Paul Murphy but was "staled" because the framework have changed since the patch was originally proposed: https://patchwork.sourceware.org/patch/10342/ [2] This part of the patch was inititally proposed as a RFC by Carlos O'Donnell. Make sense to me integrate this on the patch: https://sourceware.org/ml/libc-alpha/2017-05/msg00335.html * elf/dl-tunables.list: Add elision parameters. * manual/tunables.texi: Add entries about elision tunable. * sysdeps/unix/sysv/linux/powerpc/elision-conf.c: Add callback functions to dynamically enable/disable elision. Add multiple callbacks functions to set elision parameters. Deleted __libc_enable_secure check. * sysdeps/unix/sysv/linux/s390/elision-conf.c: Likewise. * sysdeps/unix/sysv/linux/x86/elision-conf.c: Likewise. * configure: Regenerated. * configure.ac: Option enable_lock_elision was deleted. * config.h.in: ENABLE_LOCK_ELISION flag was deleted. * config.make.in: Remove references to enable_lock_elision. * manual/install.texi: Elision configure option was removed. * INSTALL: Regenerated to remove enable_lock_elision. * nptl/Makefile: Disable elision so it can verify error case for destroying a mutex. * sysdeps/powerpc/nptl/elide.h: Cleanup ENABLE_LOCK_ELISION check. Deleted macros for the case when ENABLE_LOCK_ELISION was not defined. * sysdeps/s390/configure: Regenerated. * sysdeps/s390/configure.ac: Remove references to enable_lock_elision.. * nptl/tst-mutex8.c: Deleted all #ifndef ENABLE_LOCK_ELISION from the test. * sysdeps/powerpc/powerpc32/sysdep.h: Deleted all ENABLE_LOCK_ELISION checks. * sysdeps/powerpc/powerpc64/sysdep.h: Likewise. * sysdeps/powerpc/sysdep.h: Likewise. * sysdeps/s390/nptl/bits/pthreadtypes-arch.h: Likewise. * sysdeps/unix/sysv/linux/powerpc/force-elision.h: Likewise. * sysdeps/unix/sysv/linux/s390/elision-conf.h: Likewise. * sysdeps/unix/sysv/linux/s390/force-elision.h: Likewise. * sysdeps/unix/sysv/linux/s390/lowlevellock.h: Likewise. * sysdeps/unix/sysv/linux/s390/Makefile: Remove references to enable-lock-elision. Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
2017-12-05 16:24:14 +00:00
#if HAVE_TUNABLES
/* Elision depends on tunables and must be explicitly turned on by setting
the appropriate tunable on a supported platform. */
TUNABLE_GET (enable, int32_t,
TUNABLE_CALLBACK (set_elision_enable));
TUNABLE_GET (skip_lock_busy, int32_t,
TUNABLE_CALLBACK (set_elision_skip_lock_busy));
TUNABLE_GET (skip_lock_internal_abort, int32_t,
TUNABLE_CALLBACK (set_elision_skip_lock_internal_abort));
TUNABLE_GET (tries, int32_t,
TUNABLE_CALLBACK (set_elision_retry_try_xbegin));
TUNABLE_GET (skip_trylock_internal_abort, int32_t,
TUNABLE_CALLBACK (set_elision_skip_trylock_internal_abort));
#endif
Add elision tunables This patch adds several new tunables to control the behavior of elision on supported platforms[1]. Since elision now depends on tunables, we should always *compile* with elision enabled, and leave the code disabled, but available for runtime selection. This gives us *much* better compile-time testing of the existing code to avoid bit-rot[2]. Tested on ppc, ppc64, ppc64le, s390x and x86_64. [1] This part of the patch was initially proposed by Paul Murphy but was "staled" because the framework have changed since the patch was originally proposed: https://patchwork.sourceware.org/patch/10342/ [2] This part of the patch was inititally proposed as a RFC by Carlos O'Donnell. Make sense to me integrate this on the patch: https://sourceware.org/ml/libc-alpha/2017-05/msg00335.html * elf/dl-tunables.list: Add elision parameters. * manual/tunables.texi: Add entries about elision tunable. * sysdeps/unix/sysv/linux/powerpc/elision-conf.c: Add callback functions to dynamically enable/disable elision. Add multiple callbacks functions to set elision parameters. Deleted __libc_enable_secure check. * sysdeps/unix/sysv/linux/s390/elision-conf.c: Likewise. * sysdeps/unix/sysv/linux/x86/elision-conf.c: Likewise. * configure: Regenerated. * configure.ac: Option enable_lock_elision was deleted. * config.h.in: ENABLE_LOCK_ELISION flag was deleted. * config.make.in: Remove references to enable_lock_elision. * manual/install.texi: Elision configure option was removed. * INSTALL: Regenerated to remove enable_lock_elision. * nptl/Makefile: Disable elision so it can verify error case for destroying a mutex. * sysdeps/powerpc/nptl/elide.h: Cleanup ENABLE_LOCK_ELISION check. Deleted macros for the case when ENABLE_LOCK_ELISION was not defined. * sysdeps/s390/configure: Regenerated. * sysdeps/s390/configure.ac: Remove references to enable_lock_elision.. * nptl/tst-mutex8.c: Deleted all #ifndef ENABLE_LOCK_ELISION from the test. * sysdeps/powerpc/powerpc32/sysdep.h: Deleted all ENABLE_LOCK_ELISION checks. * sysdeps/powerpc/powerpc64/sysdep.h: Likewise. * sysdeps/powerpc/sysdep.h: Likewise. * sysdeps/s390/nptl/bits/pthreadtypes-arch.h: Likewise. * sysdeps/unix/sysv/linux/powerpc/force-elision.h: Likewise. * sysdeps/unix/sysv/linux/s390/elision-conf.h: Likewise. * sysdeps/unix/sysv/linux/s390/force-elision.h: Likewise. * sysdeps/unix/sysv/linux/s390/lowlevellock.h: Likewise. * sysdeps/unix/sysv/linux/s390/Makefile: Remove references to enable-lock-elision. Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
2017-12-05 16:24:14 +00:00
if (!__pthread_force_elision)
__elision_aconf.retry_try_xbegin = 0; /* Disable elision on rwlocks. */
Add the low level infrastructure for pthreads lock elision with TSX Lock elision using TSX is a technique to optimize lock scaling It allows to run locks in parallel using hardware support for a transactional execution mode in 4th generation Intel Core CPUs. See http://www.intel.com/software/tsx for more Information. This patch implements a simple adaptive lock elision algorithm based on RTM. It enables elision for the pthread mutexes and rwlocks. The algorithm keeps track whether a mutex successfully elides or not, and stops eliding for some time when it is not. When the CPU supports RTM the elision path is automatically tried, otherwise any elision is disabled. The adaptation algorithm and its tuning is currently preliminary. The code adds some checks to the lock fast paths. Micro-benchmarks show little to no difference without RTM. This patch implements the low level "lll_" code for lock elision. Followon patches hook this into the pthread implementation Changes with the RTM mutexes: ----------------------------- Lock elision in pthreads is generally compatible with existing programs. There are some obscure exceptions, which are expected to be uncommon. See the manual for more details. - A broken program that unlocks a free lock will crash. There are ways around this with some tradeoffs (more code in hot paths) I'm still undecided on what approach to take here; have to wait for testing reports. - pthread_mutex_destroy of a lock mutex will not return EBUSY but 0. - There's also a similar situation with trylock outside the mutex, "knowing" that the mutex must be held due to some other condition. In this case an assert failure cannot be recovered. This situation is usually an existing bug in the program. - Same applies to the rwlocks. Some of the return values changes (for example there is no EDEADLK for an elided lock, unless it aborts. However when elided it will also never deadlock of course) - Timing changes, so broken programs that make assumptions about specific timing may expose already existing latent problems. Note that these broken programs will break in other situations too (loaded system, new faster hardware, compiler optimizations etc.) - Programs with non recursive mutexes that take them recursively in a thread and which would always deadlock without elision may not always see a deadlock. The deadlock will only happen on an early or delayed abort (which typically happens at some point) This only happens for mutexes not explicitely set to PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_ADAPTIVE_NP. PTHREAD_MUTEX_NORMAL mutexes do not elide. The elision default can be set at configure time. This patch implements the basic infrastructure for elision.
2012-11-10 08:51:26 +00:00
}
#ifdef SHARED
# define INIT_SECTION ".init_array"
#else
# define INIT_SECTION ".preinit_array"
#endif
void (*const __pthread_init_array []) (int, char **, char **)
__attribute__ ((section (INIT_SECTION), aligned (sizeof (void *)))) =
{
&elision_init
};