This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Decision time: Intel TSX Lock elision for glibc.
- From: Andreas Jaeger <aj at suse dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, libc-alpha at sourceware dot org, Torvald Riegel <triegel at redhat dot com>, Rich Felker <dalias at aerifal dot cx>, Roland McGrath <roland at hack dot frob dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Tue, 02 Jul 2013 08:59:15 +0200
- Subject: Re: Decision time: Intel TSX Lock elision for glibc.
- References: <1372452807-25216-1-git-send-email-andi at firstfloor dot org> <51D0A28F dot 4070409 at redhat dot com> <51D2121F dot 4020708 at redhat dot com>
On 07/02/2013 01:34 AM, Carlos O'Donell wrote:
[...]
In summary:
* You can check patches 1, 2, 3, 4, 5, and 7
AFAIK Andi has no commit rights. Carlos, will you do it for him?
This enables elision for all DEFAULT mutexes in glibc 2.18
with a configure switch.
There are no ABI or API implications.
* Patch 6 for elision of rwlocks is going to go to the Austin
group to get clarification on what we perceive is an error
in the language of the standard. If the wording is fixed then
you won't be able to elide rwlock's since they will require
deadlock on relock behaviour (the intention of the standard).
* Patches 8 through 14 need more work, in particular we don't
have consensus on a top-down approach to setting elision for
a lock.
There is no consensus around the use of the following strategies:
- An API to direct the implementation on the use of elision.
We are talking about elision in the abstract and it's equally
applicable to multiple models of elision support in hardware.
- Use of a lock-hinting API to give the implementation enough
information to choose elision (or not).
- Use of a tunnables interface to enble elision for experimentation
via a specifically designed generic tunnables interface. The
interface is purposely unstable and would be used by users and
developers to improve the adaptive elision algorithm used in
these patches.
I know this is not what you wanted Andi, but I can't delay the
release any further for this feature. Even though it's something
that I would really like to see in 2.18 because I know there will
be Red Hat customers interested in this.
I would have loved to see this in 2.18 as well but agree that we need to
solve the questions above first.
Please let me know what you would like to do so I can call the
2.18 freeze.
Andi, Carlos, Rich, Torvald, et. al thanks a lot for the design,
implementation and improving of this critical change!
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126