linux下perf获取l2/l3缓存命中率需用事件对计算：intel用l2_rqsts.all_refs/l2_rqsts.references，通用方案用llc_references/llc_misses；禁用cache-references/cache-misses等抽象事件，避免跨架构偏差。
Linux 下用 perf 获取 L2/L3 缓存命中率（不依赖 root）
普通用户也能拿到较准确的缓存命中率，关键不是用 perf stat 直接跑程序，而是选对事件和聚合方式。L2/L3 命中率不是直接可读指标，得靠两个事件比值算出来：
-
perf stat -e 'l2_rqsts.all_refs,l2_rqsts.references' ./your_program—— 这组事件在 Intel CPU 上较稳定，references是真正发出的 L2 请求次数，all_refs是所有尝试访问 L2 的请求（含未命中后穿透到 L3 的） -
perf stat -e 'llc_references,llc_misses' ./your_program—— LLC 即 Last Level Cache（通常是 L3），这个组合更通用，但注意：ARM64 和部分新 Intel CPU（如 Sapphire Rapids）里llc_misses可能漏计某些跨核路径的 miss，需交叉验证 - 别用
cache-references/cache-misses——这是抽象层事件，底层映射不固定，不同微架构结果差异大，实测在 Skylake 上和真实 L3 miss 偏差可达 15%
内核里查实时缓存统计：/sys/devices/system/cpu/cpu*/topology/ 不行，得看 /sys/bus/event_source/devices/
/sys/devices/system/cpu 下没有缓存命中率接口，那是拓扑信息。真正在内核暴露硬件 PMU 计数器的是 /sys/bus/event_source/devices/ 目录下的子目录，比如：
-
ls /sys/bus/event_source/devices/*/type可看到每个 PMU 的 type 编号（如 Intel 是 4） - 对应计数器文件在
/sys/fs/cgroup/perf_event/或通过perf_event_open()系统调用直接绑定——但普通进程不能随意读其他 CPU 核的硬件寄存器，所以 /sys 下只暴露控制开关，不暴露实时计数值 - 想写内核模块抓 L3 miss 次数？必须用
perf_event_create_kernel_counter()注册，且需在arch/x86/events/intel/core.c里确认你用的 event code（如 0x412e）是否被intel_pebs_aliases_lbr支持，否则返回 -EOPNOTSUPP
命中率低 ≠ 一定要优化：先区分是 capacity miss 还是 conflict miss
看到 L3 命中率低于 60%，别急着改代码。用 perf record -e 'l3_sq_mshr_all,hw_cache:LLC-load-misses' -g ./app 配合 perf script 看栈，再结合以下判断：
- 如果
l3_sq_mshr_all（MISER queue 占用）高，但LLC-load-misses也高 → 很可能是 capacity miss（数据集太大塞不下 L3），考虑分块处理或压缩热点结构体字段 - 如果
LLC-load-misses高但l3_sq_mshr_all低 → 更可能是 conflict miss（多路组相联冲突），检查数组大小是否为 2 的幂次（如 4096 * sizeof(int)），导致不同热数据映射到同一 cache set；加 padding 或换用非 2 的幂长度（如 4095）常立竿见影 - 用
perf mem record -e mem-loads,mem-stores看内存访问模式：若 store-to-load forwarding 失败率高（mem-loads:u中大量MEM_INST_RETIRED.ALL_STORES关联），说明写后立即读的局部性没被 CPU 充分利用，可手动展开循环、减少中间变量
Clang/GCC 编译时绕不过的缓存陷阱：-march=native 不等于最优
-march=native 启用 AVX-512 后，某些向量化循环反而 L3 miss 暴增——因为 512-bit load 把一整 cacheline（64 字节）全拖进来，但只用其中 8 个 float，浪费带宽且挤走其他热数据。实测在 Ice Lake 上，关掉 AVX-512 改用 -mavx2 -mprefer-avx128，L3 命中率从 52% 升到 79%。
- 对密集访存循环，显式用
#pragma GCC prefetch提前加载下一块数据，比依赖硬件预取器更可控；但别 prefetch 距离超过 4 个 cache line，否则引发 TLB miss - struct 布局比编译器 flag 影响更大：把频繁一起读的字段（如
x,y,z）放在 struct 前部，冷字段（如debug_id）挪到尾部，gcc 的-frecord-gcc-switches可验证字段偏移是否紧凑 - 用
valgrind --tool=cachegrind --I1=32768,8,64 --D1=32768,8,64 --LL=8388608,16,64模拟目标 CPU 的缓存参数（注意 LL 大小要设对，错设成 4MB 会导致误判 false sharing）
最常被忽略的一点：L3 缓存是所有核共享的，但 L3 miss 的延迟在 NUMA 节点间差异极大。用 numactl --hardware 查清你的线程绑核是否跨 NUMA，跨了的话，哪怕 L3 hit rate 看着不错，实际延迟也可能翻倍——这时候得用 numactl --cpunodebind=0 --membind=0 强制同节点，而不是调编译参数。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
