Why the restricted transaction has conflict abort even run a single thread?

[zhaoguo_w_]

HI, I just run a single thread with RTM protection on a haswell machine. But it still has high conflict abort event even I just run a single thread.

[jimdempseyatthecove]

Can you show the problem with a simple reproducer?

Note, single thread can exhibit conflict/abort when:

a) The data referenced in the protected region causes a page fault
b) The hardware thread running in a protected region gets interrupted/preempted. (interruption might squeak by depending on what is touched)

Jim Dempsey

[Roman_D_Intel]

which hardware monitoring event do you use for analysing conflicts? How do you compute the abort rate?

[zhaoguo_w_]

I get the profiled data in the fallback function by using the status returned by the xbegin instruction.

I use the rtm to protect the skiplist data structure insertion routine and the abort rate is computed by using #abort divide #success.

In fact, there are three kinds of abort event: capacity, conflict, and others. Others means althrough it aborts, there is no value returned by the xbegin.

[Roman_D_Intel]

Could you post #aborts, #commits, #conflicts, #capacity, #other aborts?

[zhaoguo_w_]

I insert 1M nodes into skiplist with only one thread. So the final success transaction (#commit) number is 1000,000.

During the execution, the conflict abort number (#conflicts) is   694,078. The capacity abort number is 7,847.

The other abort number is 19,882. Total abort count is 721,807.

[Roman_D_Intel]

is there any other thread (not running transactions) that accesses the data touched in the transaction? Also consider false sharing that can cause conflicts.

can you reproduce the aborts with SDE and find their source?

[zhaoguo_w_]

There is only one thread running at the same time.  For using sde, I will get capacity conflict and never work out.

This is an interesting thing I have found between sde and the real hardware.

For sde, if we read more than 9 cache lines mapping to the same cache set, it will incur abort. But this is not true in the real hardware.

For real hardware, it can read much more memory than it can write.

[Roman_D_Intel]

Could you post #aborts, #commits, #conflicts, #capacity, #other aborts under SDE?

[zhaoguo_w_]

In fact, using sde, if there is any capacity abort, it will never work out. Or if it works out, then there is no abort event.

[Roman_D_Intel]

if there is any capacity abort, it will never work out.

it seems your RTM usage is wrong. For a recurring (capacity) abort your abort handler needs to go into a non-transactional fall-back path to make progress (one can implement a fall-back lock for example). Please consider this and this blog.

Roman

[zhaoguo_w_]

Yeah, for my rtm usage. I did't use a global lock or other kind of synchronization primitives in the fall back function. I just simply retry by re-executing the xbegin instruction, because I just want to study the RTM independently. However, it has no relationship with the cause of the abort event when I just run a single thread, right?

[Roman_D_Intel]

However, it has no relationship with the cause of the abort event when I just run a single thread, right?

it has because among other things it makes the SDE analysis impossible in your case (your program is not resilient against transactional resources overflows). Also studying something by using it in an incorrect way is not always leading to right conclusions...

Roman