c++ - 使用 haswell tsx 的神秘 rtm 中止

Question

我正在 haswell 中试验 tsx 扩展，通过调整现有的中型(1000 行)代码库以使用 GCC 事务内存扩展(在 native 中间接使用 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 block 。此运行中只有一个线程。

这个特殊的 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 的高值，它们在描述上有些相似。

Intel 手册(第 3 卷)定义了 rtm_retired_aborted_misc3 计数器:

code: C9H 20H

mnemonic: RTM_RETIRED.ABORTED_MISC3

description: Number of times an RTM execution aborted due to HLE unfriendly instructions.

tx_exec_misc1 的定义有一些相似的话:

code: 5DH 01H

mnemonic: TX_EXEC.MISC1

description: Counts the number of times a class of instructions that may cause a transactional abort was executed. Since this is the count of execution, it may not always cause a transactional abort.

我使用对 rtm_retired_aborted 的高精度 (PEBS) 支持使用 perf record/perf report 检查了中止的装配位置。该位置有一条从寄存器到寄存器的 mov 指令。附近没有看到奇怪的指令名称。

更新:

这是我从那时起尝试过的两件事:

1) 我们在这里看到的 tx_exec_misc1 和 rtm_retired_aborted_misc3 签名可以通过例如以下形式的虚拟 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);
  }
}

在这两种情况下，性能计数器看起来都与我看到的相似。然而，在这两种情况下，-e cpu/tx-abort/ 的 perf report 都指向直观正确的装配线:一个 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 芯片中的硬件错误。

Intel 指定的特定硬件错误是 HSW136 ，并且无法使用微码更新修复。事实上，我认为正是在第 4 步中，该功能不再被 cpuid 指令报告为可用，即使芯片上存在(故障)芯片来实现它也是如此。