什么是core outgoing entries？为何与CAS读写计数不匹配？

背景与测试数据 #

使用Linux perf的UNC_ARB_TRK_REQUESTS.ALL（对应事件arb/event=0x81,umask=0x1/）计算DRAM带宽，英特尔对该计数器的定义为：

已分配的核心外出条目总数，涵盖一致性与非一致性流量。

为拆分读、写传输量，尝试对应CAS读计数器unc_m_cas_count_rd和CAS写计数器unc_m_cas_count_wr，但两者计数总和与UNC_ARB_TRK_REQUESTS.ALL的数值不匹配。

执行测试命令：

perf stat -a -M DRAM_BW_Use -e unc_m_cas_count_rd,unc_m_cas_count_wr ./stream

统计结果：

Performance counter stats for 'system wide':

     3,817,362,321      unc_m_cas_count_rd
     2,444,746,789      unc_m_cas_count_wr
            85,121      arb/event=0x84,umask=0x1/        #    69.46 DRAM_BW_Use
     8,099,678,415      arb/event=0x81,umask=0x1/
     7,462,625,358 ns   duration_time

       7.462625358 seconds time elapsed

明显可见：3,817,362,321 + 2,444,746,789 ≠ 8,099,678,415。同时STREAM基准测试得出带宽约70 GB/s，说明DRAM_BW_Use未因统计ACTIVATE信号等原因被高估。

计数不匹配的原因 #

计数器层级与统计范围差异 #

1. UNC_ARB_TRK_REQUESTS.ALL（arb/event=0x81,umask=0x1/）
   属于Uncore仲裁器层级，统计的是进入DRAM仲裁队列的所有请求条目，包含但不限于最终触发CAS操作的DRAM访问：

   • 一致性协议相关请求：比如跨P核/E核的snoop响应、缓存同步请求，这类请求无需访问DRAM，但会经过Uncore仲裁器
   • 预取请求：核心发起的硬件预取请求，即使部分预取未实际触发CAS操作，仍会被统计
   • 写回请求：核心缓存的写回请求可能先进入仲裁队列，后续合并后再触发CAS，仲裁器统计的是原始请求条目数而非合并后的CAS命令数

2. unc_m_cas_count_rd/wr
   属于DRAM控制器层级，仅统计实际发送给DRAM颗粒的CAS读/写命令数，只有真正完成的DRAM数据传输才会被计数，不包含任何未触及DRAM的一致性或内部管理请求。

Alder Lake混合架构的额外影响 #

i7-12700H是P核+E核的混合架构，跨核心的一致性流量远多于纯同构架构。这类跨核心的缓存同步请求会被UNC_ARB_TRK_REQUESTS.ALL统计，但不会触发CAS读写（数据在缓存间同步，无需访问DRAM），进一步拉大了两者的计数差距。

核心概念解析 #

core outgoing entries（核心外出条目） #

指从CPU核心（P核/E核）发起的、离开核心缓存层级（L1/L2/L3）进入Uncore架构的请求条目，包含三类：

• 缓存未命中后需要访问DRAM的读/写请求
• 一致性协议要求的snoop请求、写回请求（即使最终无需写入DRAM）
• 核心发起的硬件预取请求

与CAS读写的区别 #

内容的提问来源于stack exchange，提问作者asdfldsfdfjjfddjf