Intel® ISA Extensions
Use hardware-based isolation and memory encryption to provide more code protection in your solutions.

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

zhaoguo_w_
Beginner
1,470 Views

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.

0 Kudos
12 Replies
jimdempseyatthecove
Honored Contributor III
1,470 Views

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

0 Kudos
Roman_D_Intel
Employee
1,470 Views

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

0 Kudos
zhaoguo_w_
Beginner
1,470 Views

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.

0 Kudos
Roman_D_Intel
Employee
1,470 Views

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

0 Kudos
zhaoguo_w_
Beginner
1,470 Views

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.

0 Kudos
Roman_D_Intel
Employee
1,470 Views

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?

0 Kudos
zhaoguo_w_
Beginner
1,470 Views

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.

0 Kudos
Roman_D_Intel
Employee
1,470 Views

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

0 Kudos
zhaoguo_w_
Beginner
1,470 Views

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.

0 Kudos
Roman_D_Intel
Employee
1,470 Views

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

0 Kudos
zhaoguo_w_
Beginner
1,470 Views

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?

0 Kudos
Roman_D_Intel
Employee
1,470 Views

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

0 Kudos
Reply