performance-testing - DRAM 访问的性能计数器

Question

我想检索 DRAM 访问次数 在我的应用程序中。准确地说，我需要 区分在数据和代码访问之间。处理器是 Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz (Haswell)。基于 Intel Software Developer's Manual, Volume 3和 Perf , 我可以 查找 和 分类 以下与内存访问相关的事件:

(A)
LLC-load-misses                                    [Hardware cache event]
LLC-loads                                          [Hardware cache event]
LLC-store-misses                                   [Hardware cache event]
LLC-stores                                         [Hardware cache event]
=========================================================================
(B)
mem_load_uops_l3_miss_retired.local_dram          
mem_load_uops_retired.l3_miss  
=========================================================================
(C)
offcore_response.all_code_rd.l3_miss.any_response 
offcore_response.all_code_rd.l3_miss.local_dram   
offcore_response.all_data_rd.l3_miss.any_response 
offcore_response.all_data_rd.l3_miss.local_dram   
offcore_response.all_reads.l3_miss.any_response   
offcore_response.all_reads.l3_miss.local_dram     
offcore_response.all_requests.l3_miss.any_response
=========================================================================
(D)
offcore_response.all_rfo.l3_miss.any_response     
offcore_response.all_rfo.l3_miss.local_dram       
=========================================================================
(E)
offcore_response.demand_code_rd.l3_miss.any_response
offcore_response.demand_code_rd.l3_miss.local_dram
offcore_response.demand_data_rd.l3_miss.any_response
offcore_response.demand_data_rd.l3_miss.local_dram
offcore_response.demand_rfo.l3_miss.any_response  
offcore_response.demand_rfo.l3_miss.local_dram    
=========================================================================
(F)
offcore_response.pf_l2_code_rd.l3_miss.any_response
offcore_response.pf_l2_data_rd.l3_miss.any_response
offcore_response.pf_l2_rfo.l3_miss.any_response   
offcore_response.pf_l3_code_rd.l3_miss.any_response
offcore_response.pf_l3_data_rd.l3_miss.any_response
offcore_response.pf_l3_rfo.l3_miss.any_response

我的 选择 如下面所述:

似乎 LLC-load-misses 的总和和 LLC-store-misses将返回 整体 DRAM 访问(等效地，我可以使用LLC-misses在 Perf )。

对于 纯数据 访问，我使用了 mem_load_uops_retired.l3_miss .
它不包括专卖店 , 但似乎是 好的 ( 因为 商店似乎
成为 很多不那么频繁？!)。

简单地说，LLC-load-misses - mem_load_uops_retired.l3_miss =DRAM Accesses for Code (代码为 只读 )。

这些是选择吗 合理 ?

我的其他问题:(第二个最重要)

什么是local_dram和 any_response ?

起初，似乎是， (C)组 , 是 更高分辨率 的加载事件版本(一)组 .但我的测试表明 中的事件前 组是 更频繁比后者 .例如，在 简单 基准，offcore_response.all_reads.l3_miss.any_response 的数量事件是 两次多达LLC-load-misses .

组(E) , 属于 demand reads (即所有 non-prefetched 读取)。这是否意味着，例如:offcore_response.all_data_rd.l3_miss.any_response - offcore_response.demand_data_rd.l3_miss.any_response = 预取导致的 DRAM 读取访问 ?

D组 , 包括由 Read for Ownership 引起的 DRAM 访问事件操作(用于 Cache Coherency 协议(protocol))。好像 无关的我的问题。
群(女) ，计数由 L2-cache 引起的 DRAM 读取 预取器 这也是 无关的我的问题。

Answer 1

根据我对问题的理解，我建议在指定处理器上使用以下两个事件:

OFFCORE_RESPONSE.ALL_READS.L3_MISS.LOCAL_DRAM :这包括所有可缓存的数据读写事务和所有代码获取事务，无论事务是由指令(退休与否)或预取或任何类型启动的。每个事件恰好代表对内存 Controller 的 64 字节读取请求。

OFFCORE_RESPONSE.ALL_CODE_RD.L3_MISS.LOCAL_DRAM :这包括对 IMC 的所有代码提取访问。

(我认为对于不可缓存的代码获取请求，这两个事件都不会发生，但我没有对此进行测试，并且文档对此并不清楚。)
通过从第一个事件中减去第二个事件，可以将“数据访问”与“代码访问”分开测量。这两个事件可以在 Haswell 上的同一个逻辑核心上同时计数，无需多路复用。
当然，还有其他交易确实会进入 IMC，但不计入上述两个事件中的任何一个。其中包括:(1) L3 写回，(2) 来自内核的不可缓存的部分读写，(3) 完全 WCB 驱逐，以及 (4) 来自 IO 设备的内存访问。根据工作负载，类型 (1)、(3) 和 (4) 的访问可能构成对 IMC 的总访问的很大一部分。

It seems that the sum of LLC-load-misses and LLC-store-misses willreturn the whole DRAM accesses (equivalently, I could use LLC-missesin Perf).

请注意以下事项:

事件LLC-load-misses是 perf映射到 native 事件的事件 OFFCORE_RESPONSE.DEMAND_DATA_RD.L3_MISS.ANY_RESPONSE .

事件LLC-store-misses映射到 OFFCORE_RESPONSE.DEMAND_RFO.L3_MISS.ANY_RESPONSE .

这些不是您想要的事件，因为:

ANY_RESPONSE bit 指示事件可以针对针对任何单元的请求发生，而不仅仅是 IMC。

这些事件计算 L1 数据预取和页面遍历请求，但不计算 L2 数据预取。您通常需要计算所有消耗内存带宽的预取。

For data-only accesses, I used mem_load_uops_retired.l3_miss. It doesnot include stores, but seems to be OK (because stores seem to be muchless frequent?!).

使用 mem_load_uops_retired.l3_miss 存在许多问题在哈斯韦尔:

在某些情况下，此事件是不可靠的，因此如果有替代方案，则应避免。否则，分析方法应考虑此事件计数的潜在不可靠性。

该事件仅发生在来自退役负载的请求中，它忽略了推测性负载和所有存储，这可能很重要。

以有意义的方式对这些事件和其他事件进行算术运算并不容易。例如，您执行“LLC-load-misses - mem_load_uops_retired.l3_miss = DRAM Accesses for Code”的建议是不正确的。

What are local_dram and any_response?

并非所有在 L3 中遗漏的请求都会发送到 IMC。一个典型的例子是内存映射的 IO 请求。你说你只想要发往 IMC 的核心发起的请求，所以 local_dram是正确的位。

At first, it seems that, group (C), is a higher resolution version ofthe load events of group (A). But my tests show that the events in theformer group is much more frequent than the latter. For example, in asimple benchmark, the number ofoffcore_response.all_reads.l3_miss.any_response events were twice asmany as LLC-load-misses.

这是正常的，因为 offcore_response.all_reads.l3_miss.any_response包括 LLC-load-misses并且很容易变得更大。

Group (E), pertains to demand reads (i.e., all non-prefetched reads).Does this mean that, e.g.:offcore_response.all_data_rd.l3_miss.any_response -offcore_response.demand_data_rd.l3_miss.any_response = DRAM readaccesses caused by prefeching?

没有为什么:

any_response位如上所述，

此减法仅导致 L2 数据加载预取，而不是所有数据加载硬件和软件预取。