DRAM 访问的性能计数器
Performance Counters for DRAM Accesses
我想在我的应用程序中检索 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的总和
将 return 整个 DRAM 访问（等效地，我可以使用
LLC-misses 在 Perf).
- 对于仅数据 访问，我使用了
mem_load_uops_retired.l3_miss。
它不包括 stores，但似乎是 OK（because stores seem
多 少?!).
- 简单地说，
LLC-load-misses - mem_load_uops_retired.l3_miss =
DRAM Accesses for Code（因为代码是 只读）。
这些选择合理吗？
我的其他问题：（第二个最重要）
- 什么是
local_dram 和 any_response？
- 初看起来，group (C)，是更高分辨率版本的load 组 (A) 的事件。但我的测试表明，前组中的事件比后组更频繁。例如，在 simple 基准测试中，
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 操作（对于 Cache Coherency 协议）引起的 DRAM 访问事件。似乎与我的问题无关。
Group (F)，计算由 L2-cache prefetcher 引起的 DRAM 读取，这也是 不相关的 我的问题。
根据我对问题的理解，我建议在指定的处理器上使用以下两个事件：
OFFCORE_RESPONSE.ALL_READS.L3_MISS.LOCAL_DRAM：这包括所有可缓存的数据读取和写入事务以及所有代码获取事务，无论事务是由指令（是否已退休）或预取或任何类型启动的。每个事件恰好代表对内存控制器的 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 will
return the whole DRAM accesses (equivalently, I could use LLC-misses
in Perf).
注意以下几点：
- 事件
LLC-load-misses 是映射到本机事件 OFFCORE_RESPONSE.DEMAND_DATA_RD.L3_MISS.ANY_RESPONSE 的 perf 事件。
- 事件
LLC-store-misses 映射到 OFFCORE_RESPONSE.DEMAND_RFO.L3_MISS.ANY_RESPONSE。
这些不是您想要的活动，因为：
ANY_RESPONSE 位指示事件可以针对针对任何单元的请求发生，而不仅仅是 IMC。- 这些事件计算 L1 数据预取和页面遍历请求，但不计算 L2 数据预取。您通常希望计算所有消耗内存带宽的预取。
For data-only accesses, I used mem_load_uops_retired.l3_miss. It does
not include stores, but seems to be OK (because stores seem to be much
less frequent?!).
在 Haswell 上使用 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 of
the load events of group (A). But my tests show that the events in the
former group is much more frequent than the latter. For example, in a
simple benchmark, the number of
offcore_response.all_reads.l3_miss.any_response events were twice as
many 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 read
accesses caused by prefeching?
不，因为：
any_response位如上所述，- 这种减法只会导致 L2 数据加载预取，而不是所有数据加载硬件和软件预取。
我想在我的应用程序中检索 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的总和 将 return 整个 DRAM 访问（等效地，我可以使用LLC-misses在Perf). - 对于仅数据 访问，我使用了
mem_load_uops_retired.l3_miss。 它不包括 stores，但似乎是 OK（because stores seem 多 少?!). - 简单地说，
LLC-load-misses-mem_load_uops_retired.l3_miss=DRAM Accesses for Code（因为代码是 只读）。
这些选择合理吗？
我的其他问题：（第二个最重要）
- 什么是
local_dram和any_response？ - 初看起来，group (C)，是更高分辨率版本的load 组 (A) 的事件。但我的测试表明，前组中的事件比后组更频繁。例如，在 simple 基准测试中，
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 操作（对于 Cache Coherency 协议）引起的 DRAM 访问事件。似乎与我的问题无关。
Group (F)，计算由 L2-cache prefetcher 引起的 DRAM 读取，这也是 不相关的 我的问题。
根据我对问题的理解，我建议在指定的处理器上使用以下两个事件：
OFFCORE_RESPONSE.ALL_READS.L3_MISS.LOCAL_DRAM：这包括所有可缓存的数据读取和写入事务以及所有代码获取事务，无论事务是由指令（是否已退休）或预取或任何类型启动的。每个事件恰好代表对内存控制器的 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 will return the whole DRAM accesses (equivalently, I could use LLC-misses in Perf).
注意以下几点：
- 事件
LLC-load-misses是映射到本机事件OFFCORE_RESPONSE.DEMAND_DATA_RD.L3_MISS.ANY_RESPONSE的perf事件。 - 事件
LLC-store-misses映射到OFFCORE_RESPONSE.DEMAND_RFO.L3_MISS.ANY_RESPONSE。
这些不是您想要的活动，因为：
ANY_RESPONSE位指示事件可以针对针对任何单元的请求发生，而不仅仅是 IMC。- 这些事件计算 L1 数据预取和页面遍历请求，但不计算 L2 数据预取。您通常希望计算所有消耗内存带宽的预取。
For data-only accesses, I used mem_load_uops_retired.l3_miss. It does not include stores, but seems to be OK (because stores seem to be much less frequent?!).
在 Haswell 上使用 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 of the load events of group (A). But my tests show that the events in the former group is much more frequent than the latter. For example, in a simple benchmark, the number of offcore_response.all_reads.l3_miss.any_response events were twice as many 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 read accesses caused by prefeching?
不，因为：
any_response位如上所述，- 这种减法只会导致 L2 数据加载预取，而不是所有数据加载硬件和软件预取。