meaning of RTM abort status

[Oliver_K_]

I've read 'Intel 64 and IA-32 Architectures Software/Optimization Manual' but I've some questions regarding to the RTM abort status.

Under which conditions are the bits in EAX set:

• bit 0: explicit abort, triggered by the code
  • mutual exclusive to bit 1-5?
• bit 1: indicates that abort was caused by some other conditions than explicit abort
  • mutual exclusive to bit 0
  • caused by an transient internal state of the processor and not by an interaction with another processor?
  • or is bit 1 a super-set of bits 2-5, e.g. if one of bit 2 -5 is set, bit 1 will be set too?
• bit 2: memory conflict with other processor
  • at least two processors share at least one cache-line that is part of the write-set
  • aborts:
    • all transactions?
    • all transactions except one?
• bit 3: capacity error
  • internal structures maintaining the state of the transaction overflowed
  • caused if on processor with a n-associative cache n+1 cache-lines are accessed/modified
    • is it sufficient, that the processor has n+1 cache-lines in its read-set or must the write-set contain n+1 cache-lines?
• bit 4: debug exceptions
• bit 5: nested transactions
  • exceeding of max. nested transactions
  • interweaving of HLE and RTM not supported

Are additional conditions possible?

I assume that conditions indicated by bits 3-5 are non-transient, e.g. restarting the transaction would not help.

best regards,

Oliver

[Oliver_K_]

I'm wondering in which order the abort status bits should be evaluated.

A test showed following numbers:

- version A:

if ( <explict abort> ) {
   ...
} else if ( <memory conflicts> ) {
  ...
} else if ( <may retry> ) {
  ...
} else ( // other errors
 ...
}

explicit aborts: 504

memory conflicts: 1,054,449

retry: 0

other: 84,199

- version B:

if ( <may retry> ) {
   ...
if ( <explict abort> ) {
   ...
} else if ( <memory conflicts> ) {
  ...
} else ( // other errors
 ...
}

explicit aborts: 572

memory conflicts: 180

retry: 1,319,447

other: 87,479

It seams that bit1 and bit 2 of the txn abort status are related to each other (if bit 2 is set then bit 1 is set too).

I'm unertain in which order the bits should be evaluated  - at the moment I do following:

on retry a simple PAUSE is executed:

if ( <retry> ) {
   cpu_relax(); // calls mnemonic PAUSE
}

on memory conflict (== multiple logical processors accessed the same cache-lines):

if ( <memory conflict> ) {
   std::uniform_int_distribution< std::size_t > distribution{ 0, static_cast< std::size_t >( 1) << collisions };
   const std::size_t z = distribution( generator);
   ++collisions;
   for ( std::size_t i = 0; i < z; ++i) {
        cpu_relax(); // calls mnemonic PAUSE
   }
}

Could I get some advice, please?

best regards,

Oliver

[andysem]

My understanding is that the primary bit you should be analyzing is bit 1 (retry). If that bit is 0 then there's no reason to retry the transaction regardless of the other bits, and the code must fallback to a lock-based implementation. If the bit is 1 then you may make another attempt, but it is a good idea to make a limited number of attempts, probably with a self-adjusting limit, to avoid infinite loops or poor performance.

The other bits may be interesting to analyze if your logic depends on the reason of the abort. This may be useful if the retry bit is 1, in case if you don't want to retry in some conditions. There's little reason to analyze the other bits if the retry bit is 0.