使用Perf性能指标/事件评估行缓冲区局部性的相关问题咨询

行缓冲区局部性推断可行性 #

完全可以，你提到的高延迟内存请求统计指标和行缓冲区访问的延迟特征高度匹配：
DRAM的行缓冲区命中访问延迟通常在10_{20个时钟周期，而行缓冲区冲突/缺失（需要执行预充电、新行激活操作）的访问延迟普遍在40}120个周期以上，刚好落在你提到的16/32/64/128周期的统计区间里。
你可以直接用大于32/64周期的高延迟内存请求占总内存请求的比例来推断行缓冲区局部性：比例越高，说明行冲突占比越高，局部性越差。同时用该比例乘以行冲突相对行命中的额外延迟开销，还可以直接量化局部性不足带来的性能损失。

不同程序的局部性对比可行性 #

只要测试时控制变量一致（同一硬件平台、相同内存频率/通道配置、无其他高内存负载的后台进程、仅运行目标测试程序），完全可以基于同一内存控制器下统计的高延迟内存请求占比，对比不同程序的行缓冲区局部性表现，占比越低的程序局部性越好。

相关可用性能事件清单 #

按主流处理器架构分类：

Intel x86 平台（perf事件名） #

• mem_load_retired.l3_miss：所有穿透L3缓存发往内存控制器的读请求总数，可作为计算占比的分母
• mem_load_l3_miss_retired.demand_dram_hi_latency_*：系列事件，分别统计延迟大于32、64、128、256周期的L3缺失内存读请求
• uncore_imc_*/cas_count.read：内存控制器收到的所有读CAS命令总数
• uncore_imc_*/row_buffer_miss.read：部分平台支持的内存控制器层面直接统计的行缓冲区读缺失次数

AMD x86 平台 #

• mem_load_retired.l3_miss：穿透L3的内存读请求总数
• ibs_op_latency_gt_*：基于指令采样的大于指定周期的内存操作请求统计
• uncore_imc_*/dram_access.read：内存控制器读访问总数
• uncore_imc_*/row_hit.read/row_miss.read：内存控制器层面直接统计的行命中/行缺失次数

ARM 平台 #

• mem_access_l3_miss：L3缺失的内存访问总数
• mem_access_latency_gt_*：不同延迟阈值的高延迟内存访问统计，具体事件名随ARM架构版本和厂商实现略有差异

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