linux无法直接获取“每个线程缓存命中率”，因缓存按物理核/共享域组织，线程调度动态导致perf只能按逻辑cpu（-c）采样；需用taskset绑定进程到单核后采集，或用likwid-perfctr自动计算每核l3命中率并支持多核并行对比。
perf stat -C 按 CPU 核心/线程单独采样
Linux 没有“每个线程缓存命中率”的直接指标——perf 只能按逻辑 CPU（即 -C 0、-C 1 等）采集硬件计数器，而线程调度是动态的。所以所谓“线程级对比”，实际是固定绑定到某核上运行后，再对该核采样。
关键点：必须用 taskset 或 numactl 把目标进程绑到单个逻辑 CPU，否则采样结果会混入其他线程干扰。
-
perf stat -e LLC-loads,LLC-load-misses -C 3 -- sleep 5：只采集 CPU3 的 L3 缓存加载和未命中事件 - 若想对比多个核，需分别执行：
perf stat -e ... -C 0、perf stat -e ... -C 1……再手动比对输出 - 注意：
-C参数指定的是逻辑 CPU ID（从lscpu或cat /proc/cpuinfo | grep "processor"查），不是物理核编号
用 likwid-perfctr 获取每核缓存命中率（含自动计算）
likwid-perfctr 比 raw perf 更适合做差异化对比，它内置了命中率公式，且支持多核并行采集。
安装后直接运行：
likwid-perfctr -C 0,1,2,3 -g CACHE -m ./your_app
输出中会包含每核的 L3MPKI（每千指令 L3 未命中数）、L3MISSRATE（L3 缺失率），以及自动算出的 L3HITRATE。
-
-C 0,1,2,3表示同时采集这 4 个逻辑 CPU，结果分列显示，天然支持横向对比 -
-g CACHE是预设组，覆盖 L1/L2/L3 典型事件，无需手动拼-e参数 - 如果只关心 L3，可换用
-g L3；想看 TLB 影响，加-g TLB - 不支持绑定线程，但支持绑定进程——仍需确保被测进程不跨核迁移，否则数据失真
为什么不能直接看“线程级缓存命中率”
CPU 缓存是按物理核/共享域组织的，不是按 OS 线程隔离的。一个线程在不同时间可能被调度到不同核上，而 L3 缓存通常跨多个逻辑 CPU 共享（比如超线程的两个逻辑核共用一个 L3 slice）。
因此：
- 试图用
perf stat -p <tid></tid>测单线程缓存行为，得到的是该线程所有运行时刻所在核的混合统计，无法归因 -
/proc/<pid>/status</pid>里的cpus_allowed只表示调度掩码，不等于实际运行轨迹 - 真正有意义的“差异化”，是控制变量后的对比：相同 workload，绑不同核，看
LLC-load-misses是否显著波动——这反映的是 NUMA 距离或 cache bank 冲突，而非线程本身
生成可比对的 CSV 报告（避免手动复制）
手工跑多次 perf stat 并抄数字容易出错。推荐用脚本统一采集：
for cpu in 0 1 2 3; do<br> echo "CPU${cpu}"<br> perf stat -e LLC-loads,LLC-load-misses -C $cpu -x, -- sleep 2 2>/dev/null<br>done > report.csv
这样输出是逗号分隔的纯数字，可直接导入 Excel 或用 awk 提取命中率：
awk -F, '/LLC-loads/ {loads=$2} /LLC-load-misses/ {misses=$2; print "CPU" NR/2 ": " (1-misses/loads)*100 "%"}' report.csv
-
-x,让perf stat输出用逗号分隔，便于解析 - 注意：
perf stat默认输出含单位（如 1,234,567），-x,会去掉逗号，但数字本身不含千分位符 - LLC 未命中率超过 5% 就值得警惕；若某核明显高于其他核（比如 12% vs 3%），大概率是该核对应内存控制器带宽瓶颈或 cache bank 热点冲突
真实场景里，“每个线程”只是表象，背后要抓的是「哪个物理资源域成了瓶颈」。盯住 LLC-load-misses 的分布差异，比纠结线程 ID 有用得多。
