Re: [RFC] Lock elision implementation guidelines

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2013-06-07 at 09:29 -0700, Andi Kleen wrote:
> On Fri, Jun 07, 2013 at 05:20:59PM +0200, Torvald Riegel wrote:
> > I've put those guidelines up as a page on the wiki:
> > http://sourceware.org/glibc/wiki/LockElisionGuide
> > 
> > I incorporated the comments that came up in the discussion, and tried to
> > represent the results of this discussion.  Please speak up if there are
> > points you disagree with.
> 
> I don't see much sense to write such a guide out of theoretical considerations.

Most of this is obviously about what POSIX requires in terms of mutex
semantics.  How do you propose we reason about this if not by, well,
reasoning about the semantics?  Test it on a few example programs?

> Any practical guide needs to be based on experience.

Regarding performance aspects, I agree.
Regarding semantics of existing standards, mutex types, etc.: No.
Regarding potential future semantics, I agree that lock elision is at
least a factor.  If you look at the document closer, you'll see that
some of the options discussed there are actually potential workarounds
for specific Intel HLE limitations.

> Many aspects of lock elision can be non intuitive and need validation on
> real systems.

That's one more reason actually to not mess with the semantics of
existing functionality.

> Please play around with the implementation, test it with your favourite
> applications and then write something up.

That's orthogonal to what's on the wiki page.

> I only glimpsed over it, but:
> - the trylock section discusses lots of stuff that is impractical/slow and
> doesn't cover what has been actually implemented.

That is the intent.  If you'll read it, you'll see that it argues for
what has been implemented.  This is meant to document our design, and
the discussion that lead to the decisions that we made.  Doing so
includes arguing why we didn't choose the other options.  That will make
it easier for everybody looking at this later to understand why things
are like they are.  And we don't have to argue again and again why we've
done it in a certain way.

> - it's useless to write up a "tuning roadmap" that is not resourced.
> As this is free software only what someone works on will happen.

The title is "*Possible* tuning roadmaps".  We're doing something in
between option 1 and 2 currently (depending on whether you enable LE
when building glibc).  Again, this documents the options.  If you want
to clarify what among these options we're doing, please do so.