This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Lock elision implementation guidelines
- From: Torvald Riegel <triegel at redhat dot com>
- To: Andi Kleen <ak at linux dot jf dot intel dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>, andi <andi at firstfloor dot org>
- Date: Fri, 07 Jun 2013 19:55:31 +0200
- Subject: Re: [RFC] Lock elision implementation guidelines
- References: <1360527652 dot 3065 dot 11521 dot camel at triegel dot csb> <1370618459 dot 16968 dot 11300 dot camel at triegel dot csb> <20130607162912 dot GD27861 at tassilo dot jf dot intel 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.