Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Carlos O'Donell <carlos <at> redhat.com>
Subject: Decision time: Intel TSX Lock elision for glibc.
Newsgroups: gmane.comp.lib.glibc.alpha
Date: Monday 1st July 2013 23:34:55 UTC (over 4 years ago)
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.
 
CD: 18ms