Handle abortTransaction with RTM

On 2012-11-08 15:32, Torvald Riegel wrote:
> On Thu, 2012-11-08 at 15:38 +0000, Lai, Konrad wrote:
>> The xabort argument is the only "escape" currently allowed in RTM. So it is not possible to use a separate Boolean in memory.
> 
> No, that's not what I meant.  The boolean would be used in libitm's
> htm_abort(), which the architecture-specific code (eg,
> config/x86/target.h) would then change into whatever the particular HTM
> uses as abort reasons (eg, true would become 0xff).  That's just to keep
> as much of libitm portable as possible, nothing more.
> 
>> [Roman just posted an example in http://software.intel.com/en-us/blogs/2012/11/06/exploring-intel-transactional-synchronization-extensions-with-intel-software ]
>>
>> I don't know "any" large code that uses cancel. Someone claim there is one in STAMP, and one got speed up if it was removed. I think this discussion potentially explains why.
> 
> The abort in STAMP is bogus.  They didn't instrument all of the code (if
> you use the manual instrumentation), and the abort is just there to
> "catch" race conditions and other inconsistencies.
> 
> My suggestions for next steps are to move the begin stuff to assembly.
> After that, we can go for the abort branch, if removing it really makes
> a non-negligible performance difference.

I believe this is the sort of patch that Torvald was talking about
for handling abortTransaction with RTM.

Andi, can you please test?


r~

Richard Henderson <rth@redhat.com> writes:
>  
>  static inline void
> -htm_abort ()
> +htm_abort_retry ()
>  {
>    // ??? According to a yet unpublished ABI rule, 0xff is reserved and
>    // supposed to signal a busy lock.  Source: andi.kleen@intel.com
>    _xabort(0xff);
>  }
>  
> +static inline void
> +htm_abort_cancel ()
> +{
> +  // ??? What's the unpublished ABI rule for this, Andi?

There is none for cancel, just for lock-is-locked (0xfe) and lock-busy (0xff)

The convention is just for easier abort profiling. The profiler (perf) can display
this abort code and it's far easier to understand if common situations
have their standard code. But you can always make up your own too.

-Andi

On 2012-11-08 17:23, Richard Henderson wrote:
> I believe this is the sort of patch that Torvald was talking about
> for handling abortTransaction with RTM.

FYI, I realized that this patch doesn't handle aborts on a
nested transaction properly.


r~

On Thu, 2012-11-08 at 17:23 -0800, Richard Henderson wrote:
> +         // Honor an abort from abortTransaction.
> +         else if (htm_abort_is_cancel(ret))
> +           return a_abortTransaction | a_restoreLiveVariables;

The problem is that we cannot reliably detect whether an abort with a
certain abort reason code really means that we got canceled.  A nested
transaction is one example: how do we distinguish whether the nested or
the outermost transaction were canceled?.
Another example is transaction_pure or tm_wrapper code that might reuse
the same abort reason for explicit aborts: we would like to allow
malloc() calls in transactions, but if malloc uses transactions with
explicit aborts, we might abort a transaction without a cause.

It might be possible to avoid that by carefully specifying the rules for
abort reasons, which of those can be used in nested transactions, and so
on.  But I'm not aware of any specification like that, and it seems to
likely be a pretty fragile approach.

Thus, there are two options for how to handle transactions that may
abort: Either execute them transactionally the first time, and do an
explicit HTM abort on transaction_cancel that tells libitm not not retry
as HW transaction, or execute such transactions always as SW
transactions.  Which of these two options is better depends on how
frequently transaction_cancel would actually be called.  If it's
infrequent, then trying to run as HW transactions might be better.

Torvald

On Thu, 2012-11-08 at 20:34 -0800, Andi Kleen wrote:
> Richard Henderson <rth@redhat.com> writes:
> >  
> >  static inline void
> > -htm_abort ()
> > +htm_abort_retry ()
> >  {
> >    // ??? According to a yet unpublished ABI rule, 0xff is reserved and
> >    // supposed to signal a busy lock.  Source: andi.kleen@intel.com
> >    _xabort(0xff);
> >  }
> >  
> > +static inline void
> > +htm_abort_cancel ()
> > +{
> > +  // ??? What's the unpublished ABI rule for this, Andi?
> 
> There is none for cancel, just for lock-is-locked (0xfe) and lock-busy (0xff)
> 
> The convention is just for easier abort profiling. The profiler (perf) can display
> this abort code and it's far easier to understand if common situations
> have their standard code. But you can always make up your own too.

I'm not sure this is quite true.  If a libitm-executed transaction is
started from within some other transactional region (e.g., managed
explicitly by the user), and those two disagree about what is an abort
that should be retried or not, then this can at least have a negative
impact on performance: Either because the outermost HW transaction
handler thinks it shouldn't retry even though it should, or because the
outermost transaction retries continuously even though there's no way it
can succeed.

If all code that uses transactions will eventually choose the fallback
path, this is not a correctness issue.  But it can be a performance
issue, so I think that HTMs and the code using them should be careful to
agree about abort reasons and what they communicate.


Torvald

Torvald Riegel <triegel@redhat.com> writes:
>
> I'm not sure this is quite true.  If a libitm-executed transaction is
> started from within some other transactional region (e.g., managed
> explicitly by the user), and those two disagree about what is an abort
> that should be retried or not, then this can at least have a negative
> impact on performance: Either because the outermost HW transaction
> handler thinks it shouldn't retry even though it should, or because the
> outermost transaction retries continuously even though there's no way it
> can succeed.

It shouldn't retry continuously for a nested abort.
Also retrying a lot is dangerous anyways, you have to be very
careful about that.

Short term your biggest problem is profiling the whole thing in any
case, and that is what the XABORT with well defined codes make much
easier.

-Andi

Torvald Riegel <triegel@redhat.com> writes:

> On Thu, 2012-11-08 at 17:23 -0800, Richard Henderson wrote:
>> +         // Honor an abort from abortTransaction.
>> +         else if (htm_abort_is_cancel(ret))
>> +           return a_abortTransaction | a_restoreLiveVariables;
>
> The problem is that we cannot reliably detect whether an abort with a
> certain abort reason code really means that we got canceled.  A nested
> transaction is one example: how do we distinguish whether the nested or
> the outermost transaction were canceled?.

In TSX you always come back to the outermost anyways.
Look at the nested bit in the abort code?

> Thus, there are two options for how to handle transactions that may
> abort: Either execute them transactionally the first time, and do an
> explicit HTM abort on transaction_cancel that tells libitm not not retry
> as HW transaction, or execute such transactions always as SW
> transactions.  Which of these two options is better depends on how
> frequently transaction_cancel would actually be called.  If it's
> infrequent, then trying to run as HW transactions might be better.

I believe the current evidence is that cancel is very uncommon.

-Andi

On Fri, 2012-11-09 at 10:24 -0800, Andi Kleen wrote:
> Torvald Riegel <triegel@redhat.com> writes:
> 
> > On Thu, 2012-11-08 at 17:23 -0800, Richard Henderson wrote:
> >> +         // Honor an abort from abortTransaction.
> >> +         else if (htm_abort_is_cancel(ret))
> >> +           return a_abortTransaction | a_restoreLiveVariables;
> >
> > The problem is that we cannot reliably detect whether an abort with a
> > certain abort reason code really means that we got canceled.  A nested
> > transaction is one example: how do we distinguish whether the nested or
> > the outermost transaction were canceled?.
> 
> In TSX you always come back to the outermost anyways.

That, and the fact that we cannot reliably communicate which transaction
(on the programming language level) was supposed to be aborted, is
exactly the problem that I described.

> I'm not sure this is quite true.  If a libitm-executed transaction is

It's just a convention. You don't have to use it. Not doing it will
just make abort profiling harder.

-Andi

On Fri, 2012-11-09 at 21:54 +0100, Andi Kleen wrote:
> > I'm not sure this is quite true.  If a libitm-executed transaction is
> 
> It's just a convention. You don't have to use it.

That's true ...

> Not doing it will
> just make abort profiling harder.

... but I disagree with this one.  This won't only make profiling
harder, but it also can have a negative impact on performance.  If you
think that there's something wrong with the reasons that I gave for why
this can be a performance issue, please say why you think so instead of
just saying that it's just about profiling.

To avoid the potential performance complications, it would probably be
sufficient to encourage people to follow this convention.  For example,
making sure that libitm and other libraries such as glibc are aware of
it (or, ideally, follow it) would cover most of the combinations I
suppose;  perhaps the convention should also be mentioned in the RTM
intrinsics header file.


Torvald