This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Lock elision problems in glibc-2.18
- From: Andi Kleen <andi at firstfloor dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: vogt at linux dot vnet dot ibm dot com, libc-alpha at sourceware dot org, "Kleen\, Andi" <andi dot kleen at intel dot com>
- Date: Wed, 11 Sep 2013 15:53:04 -0700
- Subject: Re: Lock elision problems in glibc-2.18
- Authentication-results: sourceware.org; auth=none
- References: <20130823084916 dot GA5506 at linux dot vnet dot ibm dot com> <1378901002 dot 3196 dot 14075 dot camel at triegel dot csb>
Torvald Riegel <triegel@redhat.com> writes:
> I agree that the abort codes can be misinterpreted. Part of the problem
> is that they form something like an ABI, but this ABI is "implicit" and
> not specified anywhere. That seems to be the case at least for TSX;
> I've asked Andi in the past for a definitive spec for those abort codes
> (i.e., the place where this ABI is defined), but didn't get a reply.
It's in the IA optimization manual.
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf
12.4.5
Can probably look into adding it to the x86-64 ABI too.
> That's true, but glibc's lock elision code will not do anything
> incorrect if it misinterprets an abort code that it gets. It might make
> a decision that's not quite optimal regarding performance, but that's
> it.
Yes it's always only a hint.
-andi
--
ak@linux.intel.com -- Speaking for myself only