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: [PATCH 3/6] Use XEND when a lock is busy in an elision attempt.


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.



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