Question

我正在试验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块。此次运行中只有一个线程。

此特定perf命令捕获Intel software developers manual vol 3中描述的大多数相关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计数大致相同（根本没有提交）
abort_conflict和abort_capacity计数为0，因此这些不是原因。另外，回想一下，只有一个线程在运行，冲突应该是罕见的。
此处唯一的实际线索是tx_exec_misc1和rtm_retired_aborted_misc3的高值，在描述上有些相似。

英特尔手册（第3卷）定义了rtm_retired_aborted_misc3个计数器：

代码：C9H 20H


助记符：RTM_RETIRED.ABORTED_MISC3


description：由于HLE不友好的指令导致RTM执行中止的次数。

tx_exec_misc1的定义有一些相似的词：

代码：5DH 01H


助记符：TX_EXEC.MISC1


description：计算可能导致事务中止的指令类的执行次数。由于这是执行计数，因此可能并不总是导致事务中止。

我使用针对rtm_retired_aborted的高精度（PEBS）支持的perf记录/性能报告检查了中止的装配位置。该位置具有从注册到注册的mov指令。附近没有看到奇怪的指令名称。

更新

以下是我尝试过的两件事：

1）我们在这里看到的tx_exec_misc1和rtm_retired_aborted_misc3签名可以通过表格的虚拟块获得

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 -e cpu/tx-abort/指向直观正确的装配线：第一个示例的xabort指令和第二个示例的syscall指令。在实际的代码库中，perf报告指向函数开头的堆栈推送：

           :    00000000004167e0 <myns::myfun()>:
    100.00 :      4167e0:       push   %rbp
      0.00 :      4167e1:       mov    %rsp,%rbp
      0.00 :      4167e4:       push   %r15

我也在intel软件开发模拟器下运行相同的命令。事实证明，在这种情况下问题就消失了：就应用程序而言，我没有中止。

Answer 1

虽然已经有一段时间了，我在搜索时发现了这个未解决的问题，所以答案是：这是Haswell和早期Broadwell芯片的硬件错误。

英特尔指定的特定硬件错误为HSW136，并且无法使用微代码更新进行修复。实际上，我认为正是在步骤4中，cpuid指令不再报告该功能可用，即使芯片上有（故障）芯片来实现它。

神秘的rtm使用haswell tsx中止

1 个答案: