linux不存在“核心线程缓存”，cpu缓存由硬件管理，不区分线程；cachetop显示page cache命中率而非cpu缓存，线程级cpu缓存需用perf绑定tid采集pmu事件，vmstat的cache统计与cpu缓存无关。
Linux没有“核心线程缓存”这个概念
这是个常见误解。Linux内核本身不为“线程”单独维护一套缓存，更不存在所谓“核心线程缓存”。CPU缓存（L1/L2/L3）是硬件层级的，由CPU核心直接管理，对所有在该核心上运行的指令一视同仁——不管它是来自进程、pthread线程，还是内核线程。所谓“线程缓存命中率”，本质是看**该线程执行路径在特定CPU核心上触发的缓存访问行为**，而不是系统给线程分配了专属缓存。
想看线程级缓存行为，得用 cachetop
cachetop 是唯一能按进程/线程维度给出实时缓存活动的工具，它基于eBPF，跟踪内核page cache的读写命中。但它显示的是**文件I/O层面的page cache命中**，不是CPU L1/L2/L3缓存。
- 安装后直接运行：
cachetop，默认每秒刷新，列包括 PID、CMD、HITS、MISSES、RATIO、DROPS - 它无法区分同一进程内的多个线程——只按PID聚合；若需线程粒度，得用
perf配合-t选项抓指定线程ID（TID） - 注意：输出中的
RATIO是 page cache 命中率，不是CPU缓存命中率，二者物理层级完全不同
要看CPU缓存（L1/L2/L3）命中，必须用 perf 并绑定到线程
真正反映CPU缓存效率的指标，只能通过 perf 采集硬件性能计数器（PMU），且必须明确指定目标线程（TID），否则统计的是整个系统或所有CPU的平均值。
- 查目标线程TID：
ps -T -p <pid></pid>或cat /proc/<pid>/task/<tid>/stat</tid></pid> - 采集L3缓存加载未命中率：
sudo perf stat -e LLC-loads,LLC-load-misses -p <tid> -- sleep 5</tid> - 采集L1数据缓存未命中：
sudo perf stat -e L1-dcache-loads,L1-dcache-load-misses -p <tid> -- sleep 5</tid> - 命中率 = (loads − load-misses) / loads × 100%，但注意：不同CPU型号事件名可能不同（如
l1d.replacement替代L1-dcache-load-misses），先用perf list | grep cache确认支持项
别把 vmstat -s | grep cache 当成命中率依据
这条命令输出的 “page cache”、“swap cache” 等全是内存管理子系统的统计量，和CPU缓存完全无关。它不包含任何“命中/未命中”计数，更无法拆解到线程粒度。试图用 grep cache 的结果计算“线程缓存命中率”，只会得出毫无物理意义的数字。
真正容易被忽略的是：CPU缓存行为高度依赖指令访问模式（空间/时间局部性）、数据对齐、是否触发预取，以及线程是否被调度到同一物理核心（影响缓存复用）。单看一次 perf stat 输出没太大价值，得在稳定负载下多次采样，再结合 perf record -e instructions,cycles,cache-misses 做火焰图分析热点函数。
