Re: [PATCH] Handle abortTransaction with RTM

[Torvald Riegel <triegel at redhat dot com>]

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