PERF STAT不计算内存负载,但计算内存存储

Question

Linux内核:4.10.0-20-generic(也在4.11.3上试过)

Ubuntu:17.04

我一直试图使用收集内存访问的统计信息perf stat.我能够收集内存存储的统计信息,但内存加载的计数返回0值.

以下是内存存储的详细信息: -

perf stat -e cpu/mem-stores/u ./libquantum_base.arnab 100
N = 100, 37 qubits required
Random seed: 33
Measured 3277 (0.200012), fractional approximation is 1/5.
Odd denominator, trying to expand by 2.
Possible period is 10.
100 = 4 * 25

 Performance counter stats for './libquantum_base.arnab 100':

       158,115,510      cpu/mem-stores/u                                            

       0.559922797 seconds time elapsed

对于内存加载,我得到0计数,如下所示: -

perf stat -e cpu/mem-loads/u ./libquantum_base.arnab 100
N = 100, 37 qubits required
Random seed: 33
Measured 3277 (0.200012), fractional approximation is 1/5.
Odd denominator, trying to expand by 2.
Possible period is 10.
100 = 4 * 25

 Performance counter stats for './libquantum_base.arnab 100':

                 0      cpu/mem-loads/u                                             

       0.563806170 seconds time elapsed

我无法理解为什么这不恰当.我应该以任何方式使用不同的事件来获取正确的数据吗？

Answer 1

该mem-loads事件被映射到MEM_TRANS_RETIRED.LOAD_LATENCY_GT_3Intel 处理器上的性能监控单元事件。事件MEM_TRANS_RETIRED.LOAD_LATENCY_*是特殊的，只能通过使用p修饰符来计数。也就是说，您必须指定mem-loads:pperf 才能正确使用该事件。

MEM_TRANS_RETIRED.LOAD_LATENCY_*是一个精确的事件，只有在精确级别进行计数才有意义。根据这篇英特尔文章（强调我的）：

当用户选择对这些事件之一进行采样时，会使用特殊硬件来跟踪数据加载从发布到完成的整个过程。这比简单地计算事件的实例（如普通的基于事件的采样）更复杂，因此只跟踪一些负载。随机选择负载，确定每个负载的延迟，并增加正确的事件（延迟 >4、>8、>16 等）。由于此事件采样的性质，任何时候都只能跟踪应用程序数据加载的一小部分。

如您所见，MEM_TRANS_RETIRED.LOAD_LATENCY_*绝不计算负载的总数，它根本不是为此目的而设计的。

如果您想确定代码中的哪些指令正在发出需要超过特定周期数才能完成的加载请求，那么MEM_TRANS_RETIRED.LOAD_LATENCY_*可以使用正确的性能事件。事实上，这正是 的目的，perf-mem它通过使用这个事件达到了它的目的。

如果要计算已停用的负载 uops 总数，则应使用L1-dcache-loads，它映射到MEM_UOPS_RETIRED.ALL_LOADSIntel 处理器上的性能事件。

另一方面，mem-stores和L1-dcache-stores映射到所有当前 Intel 处理器上的完全相同的性能事件，即MEM_UOPS_RETIRED.ALL_STORES，它确实计算了所有已停用的存储 uop。

所以总而言之，如果您正在使用perf-stat，您应该（几乎）总是使用L1-dcache-loads和L1-dcache-stores分别计算退休的负载和存储。这些映射到您在发布的答案中使用的原始事件，只是更便携，因为它们也适用于 AMD 处理器。