This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 3/6] Use XEND when a lock is busy in an elision attempt.
- From: Torvald Riegel <triegel at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: libc-alpha at sourceware dot org, "Carlos O'Donell" <carlos at redhat dot com>
- Date: Thu, 12 Sep 2013 16:57:41 +0200
- Subject: Re: [PATCH 3/6] Use XEND when a lock is busy in an elision attempt.
- Authentication-results: sourceware.org; auth=none
- References: <20130902075228 dot GA4792 at linux dot vnet dot ibm dot com> <20130902080214 dot GC4997 at linux dot vnet dot ibm dot com> <87k3izdjn8 dot fsf at tassilo dot jf dot intel dot com> <20130903082522 dot GA16924 at linux dot vnet dot ibm dot com> <87a9jtpl2j dot fsf at tassilo dot jf dot intel dot com> <1378915322 dot 3196 dot 14459 dot camel at triegel dot csb> <87ob7zhsem dot fsf at tassilo dot jf dot intel dot com>
On Wed, 2013-09-11 at 16:04 -0700, Andi Kleen wrote:
> Torvald Riegel <triegel@redhat.com> writes:
>
> >> Since z transactions and TSX are somewhat different I think it's
> >> expected that the elision code for both diverges.
> >
> > While this might eventually be true, it is something that we should
> > really try to avoid. Andi, you complained about the multiple
> > arch-specific versions of some of the pthreads code in the past, and
> > forking the elision code without need would be exactly the same problem.
> >
> > We should try really hard to keep this generic as much as possible.
> > Ideally, I'd like both of you to sit down and flesh out the adaptation
> > in more detail, and look for the commonalities there.
>
> It needs more experimentation first. I consider the current algorithm
> preliminary. We already have a better set of skip counts now
> (I had an intern working on this this summer), but there
> is still some more work needed to evaluate more options.
> I also consider this to be an area where more research would make sense.
Sounds great, thanks. I'm looking forward to hearing about the details.
> But again TSX is different from zSeries.
>
> For example the micro benchmarks Dominik was working with earlier
> behaved very different.
Sure they are different. My hope is that we can still come up with a
mostly generic adaptation mechanism, in which the arch-specific
behaviors are controlled through parameters, similar to the retry/skip
counts we have today. It's just easier for the project to maintain
these things if we have one mostly generic mechanism instead of one
different implementation for each arch; ultimately, this will benefit
all archs because it makes development more efficient.
> >> We reserved some fixed values for abort codes in the optimization guide
> >> (you can see that as a kind of ABI)
> >
> > Is this an official "Intel-blessed" document?
>
> It's Intel authored.
>
> > Can you post the link?
>
> http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf
> 12.4.5
Thanks, this is a start. The guide specifies the abort codes as
"convention used in this document", which isn't quite a request for
everyone to treat this as ABI.
Adding the abort codes to the x86-64 ABI would be good I think. What do
others think about this?
> > Who does this apply to?
>
> Everyone who wants to follow it. At least all my code and pretty much
> all of the examples use this convention.
Okay, so we at least have prior art in whatever you have touched.