我正在尝试使用 haswell 中的 tsx 扩展,通过调整现有的中型(1000 行)代码库以使用 GCC 事务内存扩展(在这台机器中间接使用 haswell tsx)而不是粗粒度锁。我正在使用 GCC 的 transactional_memory 扩展,而不是直接编写我自己的 _xbegin / _xend。我正在使用 ITM_DEFAULT_METHOD=htm
我在让它工作得足够快时遇到了问题,因为由于神秘的原因,我得到了很高的硬件事务中止率。如下所示,这些中止不是由于冲突,也不是由于容量限制。
这是我用来量化故障率和根本原因的 perf 命令:
perf stat \
-e cpu/event=0x54,umask=0x2,name=tx_mem_abort_capacity_write/ \
-e cpu/event=0x54,umask=0x1,name=tx_mem_abort_conflict/ \
-e cpu/event=0x5d,umask=0x1,name=tx_exec_misc1/ \
-e cpu/event=0x5d,umask=0x2,name=tx_exec_misc2/ \
-e cpu/event=0x5d,umask=0x4,name=tx_exec_misc3/ \
-e cpu/event=0x5d,umask=0x8,name=tx_exec_misc4/ \
-e cpu/event=0x5d,umask=0x10,name=tx_exec_misc5/ \
-e cpu/event=0xc9,umask=0x1,name=rtm_retired_start/ \
-e cpu/event=0xc9,umask=0x2,name=rtm_retired_commit/ \
-e cpu/event=0xc9,umask=0x4,name=rtm_retired_aborted/pp \
-e cpu/event=0xc9,umask=0x8,name=rtm_retired_aborted_misc1/ \
-e cpu/event=0xc9,umask=0x10,name=rtm_retired_aborted_misc2/ \
-e cpu/event=0xc9,umask=0x20,name=rtm_retired_aborted_misc3/ \
-e cpu/event=0xc9,umask=0x40,name=rtm_retired_aborted_misc4/ \
-e cpu/event=0xc9,umask=0x80,name=rtm_retired_aborted_misc5/ \
./myprogram -th 1 -reps 3000000
因此,该程序运行了一些包含事务的代码 3000 万次。每个请求涉及一个事务 gcc__transaction_atomic
块。这次运行只有一个线程。
此特定命令捕获英特尔软件开发人员手册第 3 卷perf
中描述的大多数相关 tsx 性能事件。
的输出perf stat
如下:
0 tx_mem_abort_capacity_write [26.66%]
0 tx_mem_abort_conflict [26.65%]
29,937,894 tx_exec_misc1 [26.71%]
0 tx_exec_misc2 [26.74%]
0 tx_exec_misc3 [26.80%]
0 tx_exec_misc4 [26.92%]
0 tx_exec_misc5 [26.83%]
29,906,632 rtm_retired_start [26.79%]
0 rtm_retired_commit [26.70%]
29,985,423 rtm_retired_aborted [26.66%]
0 rtm_retired_aborted_misc1 [26.75%]
0 rtm_retired_aborted_misc2 [26.73%]
29,927,923 rtm_retired_aborted_misc3 [26.71%]
0 rtm_retired_aborted_misc4 [26.69%]
176 rtm_retired_aborted_misc5 [26.67%]
10.583607595 seconds time elapsed
从输出中可以看出:
rtm_retired_start
计数为 3000 万(匹配输入到程序)rtm_retired_abort
计数大致相同(根本没有提交)- 和计数为0
abort_conflict
,abort_capacity
所以这些不是原因。另外,回想一下它只有一个线程在运行,冲突应该很少见。 - 这里唯一的实际线索是 和 的高值,
tx_exec_misc1
在rtm_retired_aborted_misc3
描述上有些相似。
英特尔手册(第 3 卷)定义了rtm_retired_aborted_misc3
计数器:
代号:C9H 20H
助记符:RTM_RETIRED.ABORTED_MISC3
描述:RTM 执行因 HLE 不友好指令而中止的次数。
的定义tx_exec_misc1
有一些类似的词:
代码:5DH 01H
助记符:TX_EXEC.MISC1
描述:计算可能导致事务中止的一类指令被执行的次数。由于这是执行计数,因此它可能并不总是导致事务中止。
我使用 perf record/perf report 使用高精度 (PEBS) 支持检查了中止的装配位置rtm_retired_aborted
。该位置具有mov
从寄存器到寄存器的指令。附近没有看到奇怪的指令名称。
更新:
从那时起,我尝试了以下两件事:
1) 我们在这里看到的 tx_exec_misc1 和 rtm_retired_aborted_misc3 签名可以得到,例如通过一个 dummy block 的形式
for (int i = 0; i < 10000000; i++){
__transaction_atomic{
_xabort(1);
}
}
或其中一种形式
for (int i = 0; i < 10000000; i++){
__transaction_atomic{
printf("hello");
fflush(stdout);
}
}
在这两种情况下,性能计数器看起来都与我看到的相似。但是,在这两种情况下,perf report
for都-e cpu/tx-abort/
指向直观正确的装配线:xabort
第一个示例的说明和syscall
第二个示例的说明。在真实的代码库中,性能报告指向函数开始时的堆栈推送:
: 00000000004167e0 <myns::myfun()>:
100.00 : 4167e0: push %rbp
0.00 : 4167e1: mov %rsp,%rbp
0.00 : 4167e4: push %r15
我也在英特尔软件开发模拟器下运行了相同的命令。事实证明,在这种情况下问题就消失了:就应用程序而言,我没有中止。