Re: Lock Elision / Transaction ABI discussion

[Dominik Vogt <vogt at linux dot vnet dot ibm dot com>]

On Mon, Sep 16, 2013 at 10:43:08AM -0700, Andi Kleen wrote:
> Dominik Vogt <vogt@linux.vnet.ibm.com> writes:
> 
> > One concern I have with a glibc-only-ABI is that abort codes are
> 
> The proposed numbers are not glibc-only, they are used
> elsewhere too.

Okay.

--

Another approach would be to not reserve specific abort status
codes but to give some of the user defined bits certain meanings.
Given the predefined codes with Tsx, that's probably difficult to
change now (0xff has all possible bits set).  On z that is a valid
approach; the lowest bit already determines whether a retry may be
useful or not (i.e. the lowest bit of the user defined abort code
is reflected in the lowest bit of the condition code of the
instruction).

As a matter of fact, the valid values for a user defined abort
code with Tsx (0 to 255) are all invalid on z (256 to 2^64 - 1),
and profiling with Haswell seems to work very differently than on
the zEC12.  As I understand, Haswell provides hardware counters
for profiling?  On the zEC12 we have to do the profiling in
software (at the time being it's a gcc patch).  As a consequence
individual abort codes may be much more important on Haswell than
on zEC12 (where I get a program address of the abort anyway as
a result of profiling).  Furthermore we'll end up with a platform
specific ABI, and it will be tedious for application programmers
to write code that is portable to multiple platforms regarding
that ABI.  As far as I understand, while the Haswell and the zEC12
implementations of transactional memory are very similar, other
cpus implement it in a very different way (e.g. Power).

--

Somewhere else Torvald asked if there is some effort by IBM to
standardize abort codes.  I'm not completely sure, but I doubt it;
if such an effort would be made, the person to trigger that would
probably be me, but I'll ask the colleagues about that.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany