Commit Graph

6 Commits

Author SHA1 Message Date
H.J. Lu
e2a32bee75 Add x86 init-arch to nptl 2013-07-03 09:22:31 -07:00
Andi Kleen
1717da59ae Add a configure option to enable lock elision and disable by default
Can be enabled with --enable-lock-elision=yes at configure time.
2013-07-02 08:46:55 -07:00
Andi Kleen
e8c659d74e Add elision to pthread_mutex_{try,timed,un}lock
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.
2013-07-02 08:46:55 -07:00
Andi Kleen
1cdbe57948 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.
2013-07-02 08:46:54 -07:00
Joseph Myers
568035b787 Update copyright notices with scripts/update-copyrights. 2013-01-02 19:05:09 +00:00
H.J. Lu
0e20515a17 Use x86-64 bits/pthreadtypes.h/semaphore.h for i386/x86-64 2012-05-30 17:29:22 -07:00