启用/禁用硬件锁定清除 [英] Enable/Disable Hardware Lock Elision

问题描述

我正在使用glibc 2.24版本.它具有通过事务同步扩展(例如_xbegin()和_xend())用于pthread_mutex_lock实现的锁定省略路径.我认为硬件应该支持锁定清除，因为 hle CPU标志用于硬件锁定清除.我使用的处理器是采用Skylake架构的Intel®Xeon®Gold 6130.

I am using glibc 2.24 version. It has lock elision path included for pthread_mutex_lock implementation with Transactional Synchronization Extensions such as _xbegin() and _xend(). The hardware is supposed to support lock elision as hle CPU flag is for Hardware Lock Elision I think. The processor I am using is Intel(R) Xeon(R) Gold 6130 with Skylake architecture.

首先，我想禁用Lock Elision，但是当我运行使用 pthread_mutex_lock 且具有 perf stat -T 来监视事务周期的程序时，我得到了0.我假设这意味着pthread_mutex_lock根本不使用事务路径.谷歌搜索之后，我发现可能有必要先使用 export GLIBC_TUNABLES = glibc.elision.enable = 1 启用锁定清除功能，但是在此步骤之后，我仍然看不到任何使用perf的事务.

First I wanted to disable Lock elision but when I run the program that uses pthread_mutex_lock, with perf stat -T to monitor transactional cycles, I got 0. I assume this means pthread_mutex_lock does not use transactional path at all. After googling I found that it might be necessary to use export GLIBC_TUNABLES=glibc.elision.enable=1 first, to enable lock elision but after this step I still don't see any transactions with perf.

另一方面，当我包含_xbegin()时；和_xend();直接在此过程中，我获得了一些具有perf stat -T的交易周期，这应该意味着我希望能找到与perf匹配的计数器.

On the other hand when I include _xbegin(); and _xend(); directly in the process, I get some number of transactional cycles with perf stat -T, which should mean that I am looking for the right counters with perf, hopefully.

因此，有关如何启用锁定清除的任何建议都将有所帮助.还是我检查不正确?

So any advice to how I can enable lock elision would be helpful. Or am I checking it incorrectly?

更新 for TSX我正在主要功能中使用以下两条说明，就像这样:

Update for TSX I'm using this two instructions in the main function, just like this:

_xbegin();
_xend();

我不确定它需要哪个库，我已经包含了其中的几十个.对于编译，我使用以下标志:-O3 -march = native -lpthread与该示例相关.

I'm not sure which library it needs, I already have tens of them included. For compilation I'm using the following flags: -O3 -march=native -lpthread that are relevant for this example.

对于锁，我有互斥锁:

pthread_mutex_t * mutex;
mutex = (pthread_mutex_t *) malloc(10 * sizeof(pthread_mutex_t));
for(int k=0; k<10; k++){
    pthread_mutex_init(&mutex[k], NULL);
  }

也许为了简化起见，我应该以不同的方式初始化它?

Maybe for elision I should initialize it differently?

推荐答案

在glibc的早期版本中，在2.27之前，只能使用称为 enable-lock-elision 的编译时标志来控制对TSX的支持.代码>.我不知道哪个版本启用或禁用了 enable-lock-elision ，但这就是它过去工作的方式 1 .因此，如果您想启用/指定TSX，则必须自己编译glibc并相应地使用该标志.从 glibc 2.27 开始，该编译时选项已被删除并由运行时间选项称为 glibc.elision.enable .也就是说，glibc始终在支持TSX的情况下进行编译，但是只有在运行应用程序之前将环境变量 glibc.elision.enable 设置为1时(例如，通过执行导出GLIBC_TUNABLES = glibc.elision.enable = 1 ).

In earlier versions of glibc, before 2.27, support for TSX could only be controlled using a compile-time flag called enable-lock-elision. I don't know which versions have enable-lock-elision enabled or disabled, but that's how it used to work¹. So if you wanted to enable/dsiable TSX, you'll have to compile glibc yourself and use that flag accordingly. Starting with glibc 2.27, that compile-time option was removed and replaced by a run-time option called glibc.elision.enable. That is, glibc is always compiled with support for TSX, but TSX will only be used if the environment variable glibc.elision.enable is set to 1 before running the application (e.g., by executing export GLIBC_TUNABLES=glibc.elision.enable=1).

在2.27之前， glibc.elision.enable 不存在，因此无效.是否使用TSX取决于编译时标志 enable-lock-elision .您正在使用2.24.因此，最简单的解决方案是将其升级到2.27或更高版本.

Before 2.27, glibc.elision.enable doesn't exist and so it has no effect. Whether TSX is used depends on the compile-time flag enable-lock-elision. You're using 2.24. So the easiest solution would be to move to 2.27 or a more recent version.

请注意，根据各自的规范更新，当前所有支持TSX的Intel处理器似乎都具有与使用Intel TSX指令可能导致不可预测的系统行为"相同的错误.对于某些处理器，英特尔已经发布了微代码更新，以实际禁用TSX.但是，将继续启用处理器上的实现.

Note that all current Intel processors that support TSX appear to have the same bug that "using Intel TSX Instructions May Lead to Unpredictable System Behavior" according to the respective specification updates. For some processors, Intel has released microcode updates to actually disable TSX. However, the implementation on your processor continues to be enabled.

脚注:

(1)根据此错误报告，从2.23开始，已在glibc中禁用了锁省略.我认为这是通过在构建glibc时禁用 enable-lock-elision 来完成的，但是我没有通过查看代码来验证这一点.但这与您在2.24中被禁用的观察一致.

(1) According to this bug report, lock elision has been disabled in glibc starting with 2.23. I think this is done by disabling enable-lock-elision when building glibc, but I've not verified this by looking at the code. But this is consistent with your observation that it is disabled in 2.24.

这篇关于启用/禁用硬件锁定清除的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！