使用haswell tsx的神秘rtm中止

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命令捕获英特尔软件开发人员手册第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 描述:由于HLE不友好的指令而中止RTM执行的次数。

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

代号: 5DH 01H 助记符: TX_EXEC.MISC1 说明:计算可能导致事务中止的类指令执行次数。由于这是执行的计数，它可能并不总是导致事务中止。

我使用perf / perf报告检查了中止的组装位置，使用对rtm_retired_aborted的高精度(PEBS)支持。该位置有一个从寄存器到寄存器的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计数器看起来都与我看到的类似。但是，在这两种情况下，perf report for -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

我还在英特尔软件开发仿真器下运行了相同的命令。结果，在这种情况下，问题就消失了:就应用程序而言，我没有被中止。

Answer 1

虽然这种情况已经发生了一段时间，但我在搜索时发现了这个未回答的问题，所以这里有一个答案:这是Haswell和早期Broadwell芯片中的一个硬件缺陷。

英特尔指定的特定硬件错误是HSW136，不能使用微码更新进行修复。实际上，我认为在第4步中，即使芯片上有(错误的)硅来实现该功能，cpuid指令也不再报告该功能可用。