分析缓存驱逐

Question

我正在寻找一个 Linux 实用程序，它允许在我的程序中分析缓存驱逐。 具体来说，我有兴趣找出导致某些缓存行反复从 L2 缓存中逐出的原因。

有什么建议吗？

Answer 1

您有多种选择，其中一些是免费的。下面我将主要讨论分析L2 未命中，不一定是L2 驱逐，因为它们或多或少是一回事。线路从 L2 被逐出，因为正在引入另一条线路，而另一条线路通常由于 L2 未命中¹而被引入。

缓存研磨

首先，我会尝试cachegrind。这基本上在一种轻量级虚拟机下运行您的二进制文件，该虚拟机允许它拦截所有内存访问并随后模拟它们对缓存的影响。它可以准确定位缓存未命中发生的位置、谁负责驱逐等等。

请务必注意，cachegrind 实际上不会告诉您硬件缓存发生了什么，而是告诉您其缓存模型中发生了什么。由于 Intel x86 上的 L1 和 L2 足够简单，因此缓存研磨模型应该是准确的，除非在特殊情况下。

Cachegrind 只能模拟两个缓存级别，但现代英特尔有 3 个或有时 4 个。不过，如果您尝试评估 L2 未命中，这应该不是问题。默认情况下，cachegrind 将 L1 缓存设置为本地 L1 缓存的检测值，并将 LLC 设置为 LLC 的检测值。在您的情况下，您需要覆盖后一个决定以反映 L2 缓存，而不是 LLC。您可以找到details in the manual，但这对于最近的 Intel Broadwell 和更早版本应该是正确的：

--LL=262144,8,64

对于 Skylake 客户/Kaby Lake 和您想要的朋友：

--LL=262144,4,64

对于 Skylake-X 服务器，您需要查找新值，因为 L2 已更改。

这种方法的主要缺点是您无法 100% 确定缓存模型准确反映了现实（例如，它不模拟预取或虚拟物理分页等事物）。另一个缺点是在 cachegrind 下运行进程可能比在本地运行它慢一个数量级，但对于“生产”之外的调查来说，这可能不是问题。

性能

您可以使用默认的、包含的和免费的分析工具来准确了解实际硬件的实际情况：perf。

特别是，您可以将perf record 与perf report 或perf annotate 结合使用来确定程序未命中的位置。你可以这样开始：

perf record -e mem_load_retired.l2_miss <your process>

这会定期记录出现 L2 未命中的位置。您可以使用perf report 显示结果，让您以交互方式浏览结果。还有很多其他选项，例如 --call-graph 来记录完整的调用图，这可能很有用。

perf record 方法总是在您代码中的哪个位置发生了某些事情，但它不能帮助您确定发生未命中时正在访问的内存 .这通常无关紧要：代码中的位置通常使访问的内存非常明显。然而，有时情况并非如此：您有一些代码可能会访问大量内存区域，并且您想知道 地址 以了解为什么会发生未命中。

在这种情况下，您可以使用perf mem，它以代码的形式记录未命中的位置和未命中的地址。这个工具没有其他工具那么完善，但至少可以使用源代码，因此您可以随时进行一些改进。我详细介绍了这个选项in another answer。

perf 的主要缺点是它的使用不如 cachegrind 之类的东西那么简单。行为和可用事件取决于您的硬件和内核版本，有时诸如堆栈跟踪之类的东西不起作用等。您必须对命令行相对熟悉才能很好地使用此工具。

VTune

此工具使用与 perf 相同的底层性能计数器，但使用基于 GUI 的探索，并且可能比 perf 更容易跳转。它需要更多的自上而下的方法：告诉您问题出在哪里并允许您向下钻取，而perf 更多的是关于“这是原始数据，找出问题所在”。

它提供了特定的分析，例如可能适合您的问题的Memory Access Analysis。

主要的缺点是这是一个付费产品，除非你qualify to use it for free。它可能比perf 更容易使用，但它仍然不是很容易，并且有很多魔法在继续，所以如果出现问题，可能很难调试。

---

¹ 在某些情况下，这可能不是真的。我能想到的主要问题是，如果预取到 L2 会导致大多数行在丢失之前到达。在这种情况下，L2 替换的数量可能会高于 L2 未命中的数量。这是cachegrind 无法为您提供帮助的那种事情，但perf 可以：您可以将 L2 行中/替换的数量与 L2 未命中的数量进行比较，看看它们是否接近。如果不是，您将不得不使用其他计数器来查看是否是预取的原因。