This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Lock elision implementation guidelines


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]