问题标签 [intel-pmu]

Mac OS 上是否有等效的性能统计信息？我想对 CLI 命令做同样的事情，而谷歌搜索并没有产生任何结果。

我想测量缓存未命中率和 dtlb 未命中率。我已经完成了第一部分。

但我找不到如何设置配置以获取 dtlb 未命中和 dtlb 命中。当我测量缓存未命中时，我确实喜欢这样：

I always thought that instructions for killing dependencies, e.g xor reg, reg do not have to be executed and are ready for retirement as soon as the Renamer moves them to the Re-order Buffer.

I just measure the number of microoperations getting into the RS with the event uops_issued.any and was surprised by the number. All the xor reg, reg for killing dependency were accounted in the perf event.

Why wouldn't just put killing dependency to ROB, without uselessly disturbing the Reservation Station?

最近的 Intel 处理器提供了一个硬件功能（又名Precise Event-Based Sampling (PEBS)）来访问有关某些 CPU 采样事件（例如 ）的 CPU 状态的精确信息e。这是英特尔 64 和 IA-32 架构的软件开发人员手册：第 3 卷的摘录：

18.15.7 处理器基于事件的采样（PEBS）

基于英特尔 NetBurst 微架构的处理器中的调试存储 (DS) 机制允许收集两种类型的信息以用于调试和调整程序：PEBS 记录和 BTS 记录。

基于Chapter 17相同的参考，x86-64架构的DS格式如下： 记录BTS Buffer最后N执行的分支（N取决于微架构），同时PEBS Buffer记录以下寄存器： IIUC，设置一个计数器，每个事件（e）发生递增它的价值。当计数器溢出时，将向这两个缓冲区添加一个条目。最后，当这些缓冲区达到一定大小（BTS Absolute Maximum和PEBS Absolute Maximum）时，会产生中断，并将两个缓冲区的内容转储到磁盘。这会定期发生。似乎--call-graph dwarf回溯数据也是在同一个处理程序中提取的，对吧？

1) 这是否意味着LBR和PEBS( --call-graph --lbr) 状态完美匹配？

--call-graph dwarf2)不属于的输出怎么样PEBS（在上面的参考中似乎很明显）？（有些RIP/RSP不匹配回溯）

准确地说，这是一个LKML Thread，其中Milian Wolff显示第二个问题是NO。但我不完全明白原因？

第一个问题的答案也是，NO（Andi Kleen在线程的后面消息中表示），我完全不明白。

3）这是否意味着整个DWARF调用图信息已完全损坏？

上面的线程没有显示这一点，在我的实验中我没有看到任何RIP不匹配的回溯。换句话说，我可以相信大多数回溯吗？

我不喜欢这种LBR方法本身可能不精确。它还受限于回溯的大小。虽然，这是一个克服尺寸问题的补丁。但这是最近的，可能是假的。

更新：

• 怎么可能强制Perf只存储一条记录PEBS Buffer？是否只能间接强制此配置，例如，当PEBS事件需要调用图信息时？

使用什么硬件功能perf来收集 Intel CPU 上 ring 0 的性能监控事件？

我的世界图是这样的：

1. 通过询问寻找免费的IA32_PERFEVTSELnMSRIA32_PERF_GLOBAL_INUSE
2. 空闲IA32_PERFEVTSELn时，它会为正在为 MSR 编程的特定计数器设置专用位，如英特尔文档第 3 卷中所述。

话虽如此，环 0 或环 3 或两者都是唯一可能的情况。

perf_event_open我正在系统调用之上进行自定义实现。

该实现旨在支持任何核心上特定线程的PERF_TYPE_HARDWARE各种事件PERF_TYPE_SOFTWARE和PERF_TYPE_HW_CACHE事件。

在Intel® 64 and IA-32 Architectures Software Developer's Manual vol 3B中，我看到以下测试 CPU（Kaby Lake）：

到目前为止，据我所知，可以同时监视（理论上）无限PERF_TYPE_SOFTWARE事件，但同时监视（没有多路复用）PERF_TYPE_HARDWARE和PERF_TYPE_HW_CACHE事件是有限的，因为每个事件都是通过 CPU 的 PMU 的有限（如上面的手册中所见）计数器数量来衡量的。

因此，对于启用了超线程的四核 Kaby Lake CPU，我假设最多可以同时监视 4 个PERF_TYPE_HARDWARE/PERF_TYPE_HW_CACHE事件（如果只使用 4 个线程，则最多可以监视 8 个）。

对上述假设进行实验后，我发现虽然我可以成功监控多达 4 个事件（对于 8 个线程），但对于最多只能同时监控 2 个事件PERF_TYPE_HARDWARE的事件，情况并非如此！PERF_TYPE_HW_CACHE

我也尝试只使用 4 个线程，但同时监视的“PERF_TYPE_HARDWARE”事件的上限仍然是 4。禁用超线程时也会发生同样的情况！

有人可能会问：为什么需要避免多路复用。首先，实现需要尽可能准确，避免多路复用的潜在盲点，其次，当超过“上限”时，所有事件值都为 0...

PERF_TYPE_HW_CACHE我要定位的事件是：

所有都使用提供的公式实现：

并作为一个群体被操纵（第一个是组长等）。

所以，我的问题如下：

1. PMU 的哪些计数器用于事件PERF_TYPE_HARDWARE，哪些用于PERF_TYPE_HW_CACHE事件，我在哪里可以找到这些信息？
2. PERF_TYPE_HARDWARE预定义事件（例如PERF_COUNT_HW_CACHE_MISSES）和事件之间有什么区别PERF_TYPE_HW_CACHE？
3. 关于如何在不复用所有列出的PERF_TYPE_HW_CACHE事件的情况下进行监控的任何建议？
4. 关于如何在不复用多达 8 个PERF_TYPE_HARDWARE或/和PERF_TYPE_HW_CACHE事件的情况下进行监控的任何建议？

提前致谢！

perf_event_open在我需要同时监控多个的基础上进行自定义实现PERF_TYPE_HW_CACHE。

英特尔手册指出，对于我的 CPU 架构，每个线程有 4 个可编程计数器（如果禁用超线程，则为 8 个）。因此，我将选择的事件分组为 1 个包含4 个事件 ( )PERF_TYPE_HW_CACHE的 perf 事件组。PERF_TYPE_HW_CACHELLC_GROUP

我进行了第一个实验，得到了以下结果：

从上面的结果可以清楚地看出，PMU 并不“适合”所有 4 个事件。我们还观察到没有实际结果的“奇怪”多路复用。

因此，作为下一步，我将 4 事件组分成 2 组，每组 2 个事件/组 ( LLC_GROUP, LLC2_GROUP)，我得到的结果如下：

使用这种配置，我们再次观察到 PMU 不能PERF_TYPE_HW_CACHE同时“适应”4，但这次（预期的）多路复用正在发生。

有人有什么解释吗？

这种行为对我来说看起来很奇怪，因为我能够在PERF_TYPE_HARDWARE没有多路复用的情况下监控多个事件（最多 6 个），而且我希望这些PERF_TYPE_HW_CACHE事件也会发生同样的情况。

我有一些我试图分析的内联程序集。有趣的是，两个非常相似的操作 maxss 和 minss 紧随其后具有非常不同的性能影响。有人有这方面的经验吗？也许是一些缓存？或者 Visual Studio 中的 CPU 使用率不正确。

当我perf list在我的 Linux 系统上运行时，我会得到一长串可用的 perf 事件。

是否可以从另一个进程中以编程方式列出和使用这些事件，使用perf_event_open(2)？也就是说，如何从另一个进程中获取此列表并确定要填充的相应值perf_event_attr？

我不是在寻找使用另一个第三方事件列表的解决方案，例如。libpfm4 或 jevents。我知道一些事件可以从其中的文件/sys/devices/cpu/events/（以及其他事件类型的类似文件）中重建，但这些只是所perf list显示事件的一小部分。

当我看到这个性能报告时，我很困惑。我试了好几次，这个setne指令总是占函数最多。该函数是一个大函数，下面仅显示一小部分函数。

该报告是通过以下方式生成的：

我检查了性能结果：

我为我最常用的代价函数之一打开了注解，很大，小块如图：

从中，我们可以看到setne指令（从顶部开始大约第 10 行，以红色显示）达到了大约 9% 的周期。

有人会帮助我吗，因为我不明白为什么这个“简单的指令”要花这么多时间？也许它与依赖于其他指令的管道排序有关？提前致谢！

顺便说一句：该程序是在 x86_64 架构上使用以下命令编译的：

以下是CPU信息：