summaryrefslogtreecommitdiff
path: root/nptl/sysdeps/unix/sysv/linux/x86
Commit message (Collapse)AuthorAgeFilesLines
* Move remaining files out of nptl/sysdeps/unix/sysv/linux/x86/.Roland McGrath2014-05-1415-548/+0
|
* Move NPTL public ABI headers for x86 to sysdeps/x86/nptl/.Roland McGrath2014-05-142-290/+0
|
* Move __PTHREAD_SPINS definition to architecture specific headerAdhemerval Zanella2014-04-091-2/+3
| | | | | | | This patch moves the __PTHREAD_SPINS definition to arch specific header since pthread_mutex_t layout is also arch specific. This leads to no need to defining __PTHREAD_MUTEX_HAVE_ELISION and thus removing of the undefined compiler warning.
* Update copyright notices with scripts/update-copyrightsAllan McRae2014-01-0113-13/+13
|
* Clean up whitespace in lock elision patches.Dominik Vogt2013-07-1912-28/+34
| | | | Signed-off-by: Carlos O'Donell <carlos@redhat.com>
* Remove remains of rwlock elision which is not implemented yet.Dominik Vogt2013-07-192-11/+0
| | | | | | | | | | | | | | | Signed-off-by: Carlos O'Donell <carlos@redhat.com> --- nptl/ 2013-07-19 Dominik Vogt <vogt@de.ibm.com> * sysdeps/unix/sysv/linux/x86/elision-conf.c: Remove __rwlock_rtm_enabled and __rwlock_rtm_read_retries. (elision_init): Don't set __rwlock_rtm_enabled. * sysdeps/unix/sysv/linux/x86/elision-conf.h: Remove __rwlock_rtm_enabled.
* Add x86 init-arch to nptlH.J. Lu2013-07-032-0/+2
|
* Add a configure option to enable lock elision and disable by defaultAndi Kleen2013-07-021-0/+3
| | | | Can be enabled with --enable-lock-elision=yes at configure time.
* Add elision to pthread_mutex_{try,timed,un}lockAndi Kleen2013-07-027-5/+127
| | | | | | | | | | | | | | | | | | | | | | | Add elision paths to the basic mutex locks. The normal path has a check for RTM and upgrades the lock to RTM when available. Trylocks cannot automatically upgrade, so they check for elision every time. We use a 4 byte value in the mutex to store the lock elision adaptation state. This is separate from the adaptive spin state and uses a separate field. Condition variables currently do not support elision. Recursive mutexes and condition variables may be supported at some point, but are not in the current implementation. Also "trylock" will not automatically enable elision unless some other lock call has been already called on the lock. This version does not use IFUNC, so it means every lock has one additional check for elision. Benchmarking showed the overhead to be negligible.
* Add the low level infrastructure for pthreads lock elision with TSXAndi Kleen2013-07-028-0/+435
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Update copyright notices with scripts/update-copyrights.Joseph Myers2013-01-022-2/+2
|
* Use x86-64 bits/pthreadtypes.h/semaphore.h for i386/x86-64H.J. Lu2012-05-302-0/+280