Re: [PATCH 5/6] Do not use explicit abort code definitions.

[Torvald Riegel <triegel at redhat dot com>]

On Mon, 2013-09-02 at 10:12 +0200, Dominik Vogt wrote:
> Using explicit abort code definitions is problematic because they are thrown at
> the creator of the outermost transaction who may misinterpret the user
> specified abort code because he does not know where it comes from.
> 
> The lock elision implementation should refrain from using explicit abort code
> definitions and rather only interpret the flags of the abort code (as should
> other pieces of software that have abort handlers).

I think that's still under discussion.  Intel seems to be fine with it,
and as I wrote in my other email in detail, I'd like to first see a more
detailed discussion on this, starting with you showing why it needs to
be this way.  We may very well end up with different policies for x86
and z, but before we split this we should know exactly why we need to.
And perhaps your case will show up issues for x86 too.

Until then, this patch shouldn't be applied in my opinion.

> On s390, the lowest bit of the explicit abort code specifies whether the abort
> is temporary or persistent.  With TSX, bit 1 of eax is used as the retry bit;
> if it's set, a retry may be worthwhile.  Is there a way to specify this bit in
> the XABORT instruction?  I cannot find anything in the Haswell documentation
> and simply assumed that the retry bit is never set when the user abort code 0
> is used.  This assumption may be wrong.

IMHO, this is another case where it would be helpful to first have a
good overview of the adaptation options that we actually have, how we
can communicate to which scenario we need to adapt, etc.  Without that,
I fear we'll just look for the needle in the haystack.