当线程可能切换内核时，如何正确使用TSX-NI（HLE和RTM）？ [英] How to properly use TSX-NI (both HLE and RTM) when threads might switch cores?

问题描述

英特尔的事务同步扩展（TSX-NI）似乎是基于每个CPU的。

It seems that Intel's Transactional Synchronization Extensions (TSX-NI) work on a per-CPU basis.

这同时适用于 _InterlockedXxx_HLE {Acquire，Release} 硬件锁定清除功能（HLE），以及 _xbegin / _xend / etc。受限事务存储（RTM）功能。

This applies to both the _InterlockedXxx_HLE{Acquire,Release} Hardware Lock Elision functions (HLE), as well as for the _xbegin/_xend/etc. Restricted Transactional Memory (RTM) functions.

在多核系统上使用这些功能的正确方法是什么？

鉴于其正确性保证，我认为我只需要担心此处的性能。

Given their correctness guarantees, I assume I only need to be worried about performance here.

所以，我应该如何构建&考虑到总是有线程突然切换内核的可能，因此编写这些代码以使我的代码具有最佳性能，因此这些指令可能需要退回到较慢的代码路径上？

So, how should I structure & write my code so that my code has the best performance, considering that there is always the chance that threads might suddenly switch cores and hence these instructions might need to fall back to slower code paths?

例如，我应该尝试显式设置线程CPU的亲和力，还是这种不好的做法？

还有其他我需要担心的事情吗？

For example, should I try to set thread CPU affinities explicitly, or is that bad practice?
Is there any other thing I should worry about?

推荐答案

如果CPU在中间中断，则事务将中止。中止是在保存RIP之前处理的，因此中断-> CPU迁移无法在此内核或其他内核上继续进行，并且无法在事务内运行 xend 。

The transaction will abort if the CPU takes an interrupt in the middle. The abort is processed before RIP is saved, so an interrupt->CPU migration can't resume on this or another core and run xend without being inside a transaction.

因此没有正确性问题。

如果操作系统的进程调度程序将线程固定在内核上，则由于缓存局部性的原因，有助于提高性能会以对工作负载次佳的方式来回弹线程。

Pinning threads to cores can help performance for cache-locality reasons, if the OS's process scheduler would otherwise be tempted to bounce threads around in a way that's sub-optimal for your workload.

B但这不会对TSX有所帮助：在中断后恢复在同一内核上再好不过，因为事务已经中止了。该内核将具有所有缓存-

But it won't help TSX specifically: resuming on the same core after an interrupt is no better, because the transaction is already aborted. That core will have all the cache-lines you need probably still hot in L1d, and hopefully still in Exclusive or Modified state.

CPU迁移仅适用于以下情况：用户空间任务，当中断使它们进入睡眠状态，而另一个内核上的内核决定捕获该任务。

CPU migrations can only happen for user-space tasks when an interrupt puts them to sleep, and the kernel on another core decides to grab that task.

在内核代码中，显然不要调用<$交易内的c $ c> schedule（）；但这对正确性并不重要，因为事务要么中止（可能），要么执行最终或迅速返回到此任务，然后我们达到 xend 并成功地将所有发生的事情一次性提交事务（包括调度程序和可能还有其他任务的所有事务）。

In kernel code, obviously don't call schedule() inside a transaction; not that it matters for correctness because either the transaction aborts (likely) or execution eventually or quickly returns to this task and we reach xend and successfully commit everything that happened as a single large transaction (which includes everything the scheduler and potentially another task did).

我实际上并没有解决这个问题，但是我认为没有理由期望TSX与非TSX的线程相似性性能考虑会显着不同。

I haven't actually played around with this, but I don't think there's any reason to expect thread-affinity performance considerations for TSX to be significantly different from non-TSX.

这篇关于当线程可能切换内核时，如何正确使用TSX-NI（HLE和RTM）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！