问题描述
我有一个 Intel(R) Core(TM) i7-4720HQ cpu @ 2.60GHz (Haswell) 处理器。我需要随着时间的推移检索对每个 DRAM 等级的访问次数，以估计其功耗。根据芯片组文档的第 261 页（即 Datasheet,volume 2 (M- and H-processor lines)），我可以使用寄存器 RAM—DRAM_ENERGY_STATUS 中的 32 位值作为 DRAM 能量估计.但我需要等级能量估计。我还可以使用核心和offcore DRAM访问性能计数器来估计功耗，但是，如前所述，我需要每个-排名统计。 除此之外，他们报告整个系统的统计数据，而能量则按等级计算。他们也没有报告许多 DRAM 访问。
因此，IMC 计数器（非核心 计数器）应该是理想的选择。 Perf不支持per-rank计数器。我尝试使用 PCM-Memory 访问 IMC 计数器信息。但是 /sys/bus/event_source/devices/uncore_imc 被内核未挂载（版本为 5.0.0-37-generic）并且该工具未检测 cpu。我尝试手动访问uncore性能计数器。 整个系统 DRAM 访问计数器已记录在案，here（它们未记录在上述芯片组手册中）。我可以使用这些计数器检索总 DRAM 读和写访问。但是，没有有关渠道或等级访问统计信息的信息。如何找到与这些计数器相关的偏移？我应该使用反复试验吗？
P.S.：Intel Software Tuning,Performance Optimization & Platform Monitoring Forum 也有此问题。
解决方法
MSR_DRAM_ENERGY_STATUS 始终报告所有内存通道的能量消耗估计。没有简单的方法可以将其分解为每级能量。该寄存器报告了对 Haswell 的高度准确的估计。
5.0.0-37-generic 内核是 Ubuntu 内核，并且支持 Haswell 上的 uncore_imc/data_reads/ 和 uncore_imc/data_writes/ 事件，它们代表来自 IMC 的数据读取 CAS 命令和数据写入 CAS 命令，分别。完整缓存行读取和完整缓存行写入事务会导致内存总线上的单个突发 64 字节事务到单个列。部分读取也作为总线上的单个全行读取执行，但由于协议中的限制，部分写入可能需要全行读取，然后是全行写入。部分写入通常可以忽略不计。
uncore_imc/data_reads/ 和 uncore_imc/data_writes/ 事件发生在针对由任何单元生成的 DRAM 内存的请求，而不仅仅是内核。这些名称由 perf 给出，它们分别对应于您引用的英特尔文章中提到的 UNC_IMC_DRAM_DATA_READS 和 UNC_IMC_DRAM_DATA_WRITES。那里提到的其他三个事件允许您分别为三个可能的来源（GT、IA 和 IO）中的每一个计算请求（不是 CAS 命令！）。您不会在旧内核的 /sys/bus/event_source/devices/uncore_imc/events 下找到它们。从主流内核 v5.9-rc2 开始，perf 支持它们。
顺便说一下，PCM 也支持这些事件，它用于报告所有通道的读写带宽，但您应该使用工具 pcm.x，而不是 pcm-memory.x ，仅适用于服务器处理器。
Haswell H 处理器系列处理器具有一个带两个 DDR3L 64 位通道的片上内存控制器。每个通道可以包含零个、一个或两个 DIMM，所有通道的总容量高达 32 GB。此外，每个 DIMM 最多可以包含两列，因此单个通道可以包含零到四列之间的任何位置。 i7-4720HQ 是一款高端移动处理器。您可能使用的是具有 8 GB 或 16 GB 内存的笔记本电脑。如果内存拓扑自购买以来没有改变，它可能只有两个 4GB 或 8GB DIMM，每个通道一个，每个通道剩余一个空闲插槽，可根据用户需要进行扩展。这意味着每个通道有一个或两个等级。
在了解物理地址如何映射到列的情况下，您可以估算对每个列的访问次数。如果每个通道都填充有相同容量的单列 DIMM，则处理器上的映射很简单。物理地址的第 6 位（即第 7 位）决定了请求映射到哪个通道，从而决定了哪个等级。您可以通过使用 perf record 选项在 MEM_LOAD_UOPS_L3_MISS_RETIRED.LOCAL_DRAM 上运行 --phys-data 在 IMC 收集一组请求的物理地址样本。显然，这组样本可能仅代表到达 IMC 的核心发起的退役负载，这是 IMC 上所有请求的一小部分。
在我看来，您想测量每列内存访问的次数，以便从总 DRAM 能量中估计每列能量，但由于以下原因，这根本不是微不足道的：
- 并非所有 CAS 命令都具有相同的能量成本。预充电和激活命令不计入任何事件，可能会消耗大量能量，尤其是在行缓冲区未命中率较高的情况下。
- 即使 IMC 中的请求为零，只要至少有一个活动内核，内存通道就会被供电并且确实会消耗能量。
- 由于等级到等级的周转和读写切换所需的时间延迟，处理相同类型和相同地址的请求所需的时间可能因周围的请求而异。
尽管如此，我想还是有可能建立一个良好的每级能量上限和下限模型，如果对每个等级的请求数量有代表性的估计（如上所述）。
>最重要的是，没有简单的方法可以像在服务器处理器上那样享受按等级计数的奢侈。