问题标签 [intel-pmu]

我想知道是否有任何单个事件可以捕获 L1D 缓存未命中。我试图通过测量延迟以在开始时使用 rdtsc 访问特定内存来捕获 L1d 缓存未命中。在我的设置中，如果发生 L1d 缓存未命中，它应该会命中 L2 缓存。因此，我用 RDTSC 测量访问内存的延迟，并将其与 L1 缓存延迟和 L2 缓存延迟进行比较。但是，由于噪音，我无法辨别它是击中 L1 还是 L2。所以我决定使用 RDPMC。

我发现有几个 API 提供了一些功能来轻松监控 perf 事件，但我想直接在我的测试程序上使用 RDPMC 指令。我发现 MEM_INST_RETIRED.ALL_LOADS-MEM_LOAD_RETIRED.L1_HIT 可用于计算 L1D 中未命中的已退休加载指令的数量。（使用 PAPI_read_counters 计算 L1 缓存未命中会产生意外结果）。但是，这篇帖子似乎在谈论 papi Api。

在执行 rdpmc 指令以捕获特定事件之前，如何找到应该为 ecx 寄存器分配哪些值？另外，我想知道是否有任何单个事件可以告诉我在两条 rdpmc 指令之间的一条内存加载指令发生 L1 未命中，如下所示。

我目前正在使用 9900k 咖啡湖机，所以我在英特尔手册中搜索了咖啡湖机的 perf counter number。似乎只在加载指令之前和之后捕获两个 MEM_LOAD_RETIRED.L1_HIT 就足以捕获事件，但我不确定这样做是否可以。我也不知道如何将该 perf 事件编码为ecx 寄存器。

最后，我想知道 rdpmc 指令背靠背是否需要任何序列化指令。就我而言，因为我只放置了加载指令并测量 L1d 缓存未命中是否发生，所以我将第一条 rdpmc 指令与 lfence 指令括起来，并在最后一条 rdpmc 之前再放置一条 lfence 指令，以确保加载指令在第二条 rdpmc 之前完成。

添加代码

我还用 isolcpu 固定了我的 3 号核心，并禁用了超线程进行测试。MSR 寄存器已用以下命令计算

我想获得在 Linux 机器上运行的 C/C++ 程序 ( foo ) 的特定功能的缓存命中率。我正在使用 gcc 并且没有编译器优化。使用perf，我可以使用以下命令获得整个程序的命中率。

perf stat -e L1-dcache-loads,L1-dcache-load-misses,L1-dcache-stores,L1-dcache-store-misses ./a.out

但我只对内核foo感兴趣。

有没有办法使用perf或任何其他工具仅获得foo的命中率？

lscpu 命令的输出是：

我正在尝试使用 perf 在我的机器上测量某些事件，包括 L1-dcache-stores，与内核 3.10.0-1127 的相对较旧的 CentOS 7 相比，它具有相对较新的处理器 i9-10900K

问题是 perf 报告 L1-dcache-stores 以及其他一些事件在我运行时不受支持perf stat -e L1-dcache-stores，所以我不能使用它，至少以我知道的直接方式。然而，在内核为 4.18.0-193 的 CentOS 8 下，perf 在同一台机器上可以正常工作。所以，我怀疑这是因为旧内核不知道如何处理太新处理器上的某些性能计数器，而 perf 本质上是内核的一部分。

我该怎么做才能在 CentOS 7 系统上使用 perf 并让 L1-dcache-stores 之类的东西在我的处理器上正常工作？我不能只从 CentOS 8 获取 perf 二进制文件并在 CentOS 7 上使用它，因为 glibc 版本不同。

我正在尝试找到一个 PMC（性能监控计数器），它将显示prefetcht0指令命中 L1 dcache（或未命中）的次数。

icelake 客户端：Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz

我正在尝试制作这种细粒度的即（注意应包括lfence周围prefetcht0）

目标是检查预取是否命中 L1。如果没有执行一些准备好的代码，否则继续。

仅基于可用的内容，它似乎必须是一个错过事件。

我尝试了libpfm4和 intel 手册中的一些事件，但没有成功：

L1D.REPLACEMENT和L1-DCACHE-LOAD-MISSES一种作品，如果我延迟它会起作用，rdpmc但如果它们一个接一个，它似乎充其量是不可靠的。其他的都是完整的半身像。

问题：

1. 这些是否可以用于检测预取是否命中 L1 dcache？（即我的测试很糟糕）
2. 如果不。什么事件可用于检测预取是否命中 L1 dcache？

编辑：MEM_LOAD_RETIRED.L1_HIT似乎不适用于软件预取。

这是我用来做测试的代码：

如果我将DO_PREFETCH结果定义为MEM_LOAD_RETIRED.L1_HIT始终为 1（似乎总是受到打击）。如果我注释掉DO_PREFETCH结果与我所期望的一致（当地址显然不在缓存中时报告未命中，当它显然是报告命中时）。

与DO_PREFETCH：

并且没有DO_PREFETCH

有了L2_RQSTS.SWPF_HIT并且L2_RQSTS.SWPF_MISS能够让它工作。非常感谢哈迪·布雷斯。值得注意的是，L1D_PEND_MISS.PENDING不起作用的原因可能与 Icelake 有关。Hadi Brais 报告说，它可以用于预测 Haswell 上的 L1D 缓存未命中。

为了试图确定为什么不工作L1_PEND_MISS.PENDING，MEM_LOAD_RETIRED.L1_HIT发布了我用来测试它们的确切代码：

我有一个Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz( Haswell) 处理器。AFAIKmem_load_uops_retired.l3_miss计算DRAM demand（即non-prefetch）数据读取访问次数。offcore_response.demand_data_rd.l3_miss.local_dram顾名思义，计算demand针对 DRAM 的数据读取次数。因此，这两个事件似乎是等价的（或至少几乎相同）。但基于以下基准，前一个事件的频率远低于后者：

1) 在循环中初始化 1000 个元素的全局数组C：

2) 在 Evince 中打开 PDF 文档：

3) 运行 Wireshark 5 秒：

4) 在 Inkscape 中对图像运行模糊滤镜：

在所有四个基准测试中，频率几乎offcore_response.demand_data_rd.l3_miss.local_dram是. 这合理吗？为什么？请告诉我基准是否过于复杂和粗粒度！mem_load_uops_retired.l3_miss

我有一个Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz( Haswell) 处理器。随着时间的推移，我需要检索每个 DRAM rank的访问次数，以估计其功耗。根据芯片组文档的页面（即数据表，第 2 卷（M 和 H 处理器线）），我可以使用寄存器中的 32 位值，作为 DRAM 能量估计。但我需要等级能量估计。我还可以使用核心和非核心DRAM 访问性能计数器来估计功耗，但是，如前所述，我需要per-rank 统计信息。除此之外261RAM—DRAM_ENERGY_STATUS，他们报告整个系统的统计数据，而能量是按等级计算的。他们也没有报告许多 DRAM 访问。

因此，IMC计数器（非核心计数器）应该是理想的选择。Perf不支持per-rank计数器。我尝试使用来访问柜台信息。但是没有被内核挂载（版本是）并且该工具没有检测到 CPU。我试图手动访问非核心性能计数器。此处记录了整个系统DRAM 访问计数器（它们未记录在上述芯片组手册中）。我可以找回PCM-MemoryIMC/sys/bus/event_source/devices/uncore_imc5.0.0-37-generic使用这些计数器的总DRAM读取和写入访问。但是，没有关于频道或等级访问统计的信息。如何找到与这些计数器关联的偏移量？我应该使用反复试验吗？

PS：这个问题也在英特尔软件调优、性能优化和平台监控论坛上提出。

我有一个Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz( Haswell) 处理器。在相对空闲的情况下，我运行了以下Perf命令，它们的输出如下所示。计数器是offcore_response.all_data_rd.l3_miss.any_response和mem_load_uops_retired.l3_miss：

这两个值似乎是一致的，因为后者不包括 预取请求和那些不针对的请求DRAM。但它们与IMC. 此处调用UNC_IMC_DRAM_DATA_READS并记录了此计数器。我读了柜台，然后再读了一遍。差异在(EDITED)左右。如果乘以（估计秒数），结果值将约为百万(EDITED)，这是上述值的倍数130,000,000 1010300100 性能计数器（已编辑）。远不及百万3！我错过了什么？

PS：当系统负载更大时，差异要小得多（但仍然很大）。

问题也在这里提出： https ://community.intel.com/t5/Software-Tuning-Performance/Performance-Counters-and-IMC-Counter-Not-Matching/mp/1288832

更新：

请注意，PCM输出与我的IMC计数器读数相匹配。

这是相关的输出PCM： 列和的值READ分别基于和计算。似乎分类为的请求将是或。换句话说，在所描绘的一秒间隔内，GB 和请求的GB几乎（由于上述文档中报告的不准确）属于. 基于这个解释，以上WRITEIOUNC_IMC_DRAM_DATA_READSUNC_IMC_DRAM_DATA_WRITESUNC_IMC_DRAM_IO_REQUESTSIOREADWRITE2.012.42READWRITEIO三列似乎彼此一致。

问题是和值之间仍然存在很大的差距！IMCPMC

当我在runlevel启动时情况是一样的。调度程序上的进程是和之一。磁盘 IO几乎是KB/s。我想知道是什么导致了如此（相对）大量的. 是否可以检测到（例如，使用 a或tool）？ 1 swapperkworkermigration85IOcounter

更新 2：

我认为专栏有问题。无论系统中的负载量如何，IO它总是在范围内！[1.99,2.01]

更新 3：

在runlevel1中，事件在1 秒间隔内的平均发生次数为。在同一时期，相关计数器记录的读取请求数约为. 也就是说，假设所有的内存访问都是由cpu指令直接引起的，那么对于每一个退役的微操作，都会存在两次内存访问。特别是考虑到存在多级缓存这一事实，这似乎是不可能的。因此，在uops_retired.all15,000,000IMC30,000,000空闲情况下，读取访问可能是由IO.

我有最新的咖啡机，主要用作存储服务器。单独运行存储服务器时，每个核心（4 个核心）的平均工作负载约为 5-10%。

我想使用英特尔采样驱动程序在这台机器上运行工作负载的 vtune 测量。但是，考虑到存储服务器应用程序同时运行，我怀疑测量是否准确。

但是正如英特尔的文件所暗示的那样，采样驱动程序安装在 Linux 内核上，那么如果与其他应用程序同时运行，测量结果是否真的会不准确呢？换句话说，英特尔采样驱动程序究竟是如何工作的？他们是否能够区分工作负载进程和系统上运行的其他进程？

我正在使用 Linux 5.8.18 进行性能调整，然后我遇到了困惑。
X86 中的 PMU 资源有限，perf 是使用 PMU 完成 profiling/sampling 的工具。
IIRC，性能文档说 PMU 资源由不同的进程共享，因此 Linux 内核将在进程调度期间保留/快照 PMC。

为了验证 PMU 设置是否特定于进程，我进行了以下测试。
在后台运行以调用 perf API 以在 CPU0 上启用和使用 X86 FIXed_Counter0（指令已停用）（MSR 0x309）的进程。
然后在bash中，我rdmsr -p0 0x309，我发现当进程在后台运行时计数器正在增加。

我曾认为每个进程（A 和 Bash）都应该有自己的 PMC 快照（在本例中为 FIXed_Counter0），但测试表明 PMC 是全局可见的......

我真的很困惑。

I am running a C++ benchmark test for a specific application. In this test, I open the performance counter file (__NR_perf_event_open syscall) before the critical section, proceed with the section and then after read the specified metric (instructions, cycles, branches, cachemisses, etc).

I verified that this needs to run under sudo because the process needs CAP_PERFCOUNT capabilities. I also have to verify that /proc/sys/kernel/perf_event_paranoid is set to a number higher than 2, which seems to be always the case with Ubuntu 20.04.3 with kernel 5.11.0 which is the OS I standardized across tests.

This setup works on all my local machines. On the cloud, however, it works only on some instances as m5zn.6xlarge (Intel Xeon Platinum 8252C). It does not work on others as t3.medium, c3.4xlarge, c5a.8xlarge.

The AMI on all them are the same ami-09e67e426f25ce0d7.

One easy way to verify this behavior is run the following command:

On the m5zn box I will see:

Perf with valid output

While on the other boxes I will see:

Perf with not supported values

My suspicion is that the m5zn.6xlarge is backed by a real instance while the others are shared instances. is my suspicion correct?

What instances I can launch that will provide me with performance counter PMU support?

Thank you!