- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
which hardware monitoring event do you use for analysing conflicts? How do you compute the abort rate?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you post #aborts, #commits, #conflicts, #capacity, #other aborts?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you post #aborts, #commits, #conflicts, #capacity, #other aborts under SDE?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
![](/skins/images/D2683F18326913BBA0436CB7114DD569/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page