This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Decision time: Intel TSX Lock elision for glibc.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: 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>, Andreas Jaeger <aj at suse dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Mon, 01 Jul 2013 19:34:55 -0400
- Subject: 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>
On 06/30/2013 05:26 PM, Carlos O'Donell wrote:
> At present I feel that patches 1 - 7 could be committed immediately
> as a no-ABI/no-API checkpoint for elision which would allow you to
> build and test with elision turned on via configuring with
> --enable-elision=yes.
>
> The only thing that blocks this is a need for consensus on patch
> #6 to add elision to rwlocks. I would like someone else to agree
> with Andi and my interpretation that deadlock on relock is not
> required by POSIX for rwlocks.
>
> Patches 8 through 14 are under review.
In summary:
* You can check patches 1, 2, 3, 4, 5, and 7
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.
Please let me know what you would like to do so I can call the
2.18 freeze.
Cheers,
Carlos.