perf stat 直接看 cache-references 和 cache-misses 是最轻量通用的实时监控方式，命中率 = (1 − cache-misses / cache-references) × 100%，x86_64 下通常指 llc（l3）层级，但需注意该指标是硬件抽象，不等于 uncore 级精确 l3 命中率；正确做法应使用 uncore_imc/uncore_cha 等事件获取真实 l3 数据。
perf stat 直接看 cache-references 和 cache-misses
perf stat 是最轻量、最通用的实时监控方式，不需要额外安装，只要内核启用了 PMU（绝大多数现代 CPU 都支持）。它不显示“命中率”百分比，但给出原始计数，你自己一除就完事——这才是真正反映硬件行为的数据。
-
cache-references 是缓存访问总次数（含命中+未命中），cache-misses 是未命中次数
- 命中率 = (1 −
cache-misses / cache-references) × 100%
- 注意：这个事件在不同 CPU 架构上语义略有差异（比如某些 ARM 上可能只统计 L2/L3），x86_64 通常指 LLC（L3）层级
- 示例命令：
sudo perf stat -e cache-references,cache-misses -C 7 sleep 5
这会绑定到 CPU7，采样 5 秒。输出类似：
12,345,678 cache-references
1,234,567 cache-misses
# => 命中率 ≈ 90.0%
- 容易踩坑：不加
-C 或 -a 时，默认只监控当前 shell 所在 CPU，不是全局；如果目标进程跑在 CPU0～3，却监控 CPU7，数据完全无效
按缓存层级拆解：LLC / L1-dcache / L2-dcache
cache-references 太笼统，实际调优常需定位是哪一级缓存拖后腿。Linux
perf 支持细粒度事件，但必须查清楚你 CPU 支持哪些——别硬写不存在的事件名。
- 先确认可用事件：
perf list | grep -i "cache|llc|dcache"
- 常见有效事件（x86_64 Intel/AMD）：
LLC-loads, LLC-load-misses（L3 加载相关）
L1-dcache-loads, L1-dcache-load-misses（L1 数据缓存）
L2-dcache-loads, L2-dcache-load-misses（部分 CPU 支持，非所有型号）
- 示例（监控 L1 数据缓存）：
sudo perf stat -e L1-dcache-loads,L1-dcache-load-misses -C 7 ./your_program
- 关键点：
L1-dcache-load-misses 不等于 “去 L2 取”，它包含 L1 miss + L2 miss + 最终从内存取的全部路径；真正的“跨级漏出”需结合多级事件交叉分析
某些老内核或虚拟机环境可能不暴露 L2 事件，强行用会报 event not supported
用 likwid-perfctr 看带百分比的汇总视图
如果你需要一眼看到命中率数字（而不是自己算），
likwid-perfctr 是目前最省心的选择，尤其适合快速验证。
别指望 /proc/meminfo 或 vmstat 给你缓存命中率
/proc/meminfo 里的
Cached、
Buffers，或者
vmstat -s | grep cache 输出的“page cache hits”之类，全是 **页缓存（page cache）** 统计，和 CPU 的 L1/L2/L3 缓存完全无关。
- 页缓存是内核为文件 I/O 做的软件层缓存，单位是 page（通常 4KB）
- CPU 缓存是硬件电路实现的、面向 cache line（通常 64B）的极小粒度高速存储
- 两者不在一个抽象层级，混用会导致严重误判。比如
free -h 显示 cached 很高，不代表 CPU 缓存命中率高；反之亦然
- 真正容易被忽略的点：很多文档把“cache hit rate”当做一个统一指标讲，但没说清是 哪个 cache —— 问清楚场景再选工具，否则花半天调参，监控的却是两回事
