TSX conflict aborts for single threaded applications

[BGoel]

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?

[krahnack]

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.

[BGoel]

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).

[Andreas_K_Intel · Accepted solution]

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.

[BGoel]

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

[BGoel]

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!

[BGoel]

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.