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: GLIBC Devel <libc-alpha at sourceware dot org>
- Cc: Andi Kleen <ak at linux dot jf dot intel dot com>
- Date: Tue, 11 Jun 2013 15:05:41 +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> <20130610114346 dot GA1384 at linux dot vnet dot ibm dot com> <1370890159 dot 16968 dot 12558 dot camel at triegel dot csb> <20130611075118 dot GA3946 at linux dot vnet dot ibm dot com>
On Tue, 2013-06-11 at 09:51 +0200, Dominik Vogt wrote:
> On Mon, Jun 10, 2013 at 08:49:19PM +0200, Torvald Riegel wrote:
> > You cited the "Focus on PNT, allow E" option, but I'm not sure what kind
> > of conclusions you draw from your test, and how it relates to this
> > option. Would you like to have a very conservative default tuning? Or
> > do you think that lock elision should only be enabled explicitly on z
> > architecture? Or what else?
>
> For the moment my conclusion is: HTM is tricky. It often sounds
> promising, but then in real code there are many little details
> that may prevent you from harvesting the benefits.
Yes it's not a silver bullet. That's a motivation for enabling it
conservatively first, so that users hopefully don't run into those
little details too often.
> > > P.S.: Test run with default tuning values; I think it switches
> > > to real locks after three failed transactions, and back to
> > > transactions after three real locks. I'm quite sure that given
> > > _any_ set of tuning parameters, I can write you a test program
> > > that has similarly bad performance using elision.
> >
> > Certainly not for _any_. For example, if we don't use elision anymore
> > at all after 10 failed attempts globally, I guess the performance
> > degradation that elision would cause would be pretty limited :)
>
> We'll see about that. ;-) Don't forget that even if elision is
> disabled, the mere fact that elision is compiled in and that there
> possibly is an additional function call slows down
> pthread_mutex_lock.
Andi said that in his measurements, the overhead would be negligible.
Could any of you share the actual numbers?
> > Thanks for making the test, and it would be interesting if you can
> > investigate this further, post more results, and perhaps experiment with
> > different tuning options. As Andi said, this data is necessary input to
> > see which steps we need to take to make use of elision.
>
> I have done a lot of testing on zEC12 with HTM, and I'm certainly
> willing to write and run tests and provide data; but at the moment
> I have to be careful with what I post because the legal clearance
> process is slow. :-/
Understood.