Software Tuning, Performance Optimization & Platform Monitoring
Discussion regarding monitoring and software tuning methodologies, Performance Monitoring Unit (PMU) of Intel microprocessors, and platform updating.

TSX conflict aborts for single threaded applications

BGoel
Beginner
596 Views

Hi,

I have just started running STAMP (Transactional Memory benchmarks from Stanford) on Haswell. I am monitoring the TSX performance using libpfm4.4 library on Ubuntu (kernel 3.11-rc6). When I run single-threaded transactional memory benchmarks, I see transaction aborts due to data conflicts (TX_MEM.ABORT_CONFLICT) for certain benchmarks. This behavior seems strange to me considering that I am running single-threaded benchmark, so there shouldn't be any data conflicts on transactionally accessed address. Is there something that I am missing?

0 Kudos
1 Solution
Andreas_K_Intel
Employee
596 Views

A low background number of such conflict aborts is expected even in the single CPU case.

As another note: STAMP is not very interesting in general. Please test it with real applications.

View solution in original post

0 Kudos
6 Replies
krahnack
Beginner
596 Views

Hi, I don't work with Intel, but my not-so-far fetched guess here is that since TSX uses cache coherency protocol to keep track of the conflicts, some false conflicts can occur, depending on the cache traffic.

from the Intel optimisation manual (section 12.2.3.5):

In addition to the above, implementation-specific conditions and background system activity may cause
transactional aborts. Examples include aborts as a result of the caching hierarchy of the system, subtle
interactions with processor micro-architecture implementations, and interrupts from system timers
among others. Aborts due to such activity are expected to be fairly infrequent for typical Intel TSX usage
for lock elision.

0 Kudos
BGoel
Beginner
596 Views

Thanks. I am not sure about this. I see conflict aborts even when only 1 CPU is activated from the BIOS. Second, my assumption would be that aborts due to reasons as described in paragraph mentioned by you would show up as RTM_ABORTED.MISC2/RTM_ABORTED.MISC5 instead of RTM_ABORTED.MISC1 (and TX_MEM:ABORT_CONFLICT).

0 Kudos
Andreas_K_Intel
Employee
597 Views

A low background number of such conflict aborts is expected even in the single CPU case.

As another note: STAMP is not very interesting in general. Please test it with real applications.

0 Kudos
BGoel
Beginner
596 Views

Thanks Andreas. Can you tell me what results in conflict aborts (specifically TX_MEM:ABORT_CONFICT) for single CPU?

0 Kudos
BGoel
Beginner
596 Views

I have also noticed that sometimes the count for TX_MEM:ABORT_CONFLICT exceeds the count for RTM_RETIRED.ABORTED_MISC1, which as per section 12.4.10 shouldn't happen since it suggests calculating the aborts due to resource limitations by substracting TX_MEM:ABORT_CONFLICT from RTM_RETIRED.ABORTED_MISC1!

0 Kudos
BGoel
Beginner
596 Views

As per this Intel blog: http://software.intel.com/en-us/blogs/2013/06/14/monitoring-intel-transactional-synchronization-extensions-with-intel-pcm  multiple abort signals may count as one in a different category and hence TX_MEM.ABORT_CONFLICT > RTM_RETIRED.ABORTED_MISC1 is possible. So the question is, how can I accurately count the aborts due to buffer overflows. And I still don't understand the events that result in TX_MEM.ABORT_CONFLICT counts for single CPU case.

0 Kudos
Reply