Linux perf是唯一能在生产环境稳定获取真实L3缓存命中率的工具，需用uncore_cbox_XX:LLC_MISSES/LLC_REFERENCES等硬件事件精确计算，而非cache-misses等软件抽象指标。
Linux 下用 perf 直接读取 L3 cache 命中率（非估算）
Linux perf 是唯一能在生产环境稳定获取真实 L3 cache 命中率的工具，不需要 root 权限也能采集部分事件，但要完整命中/缺失计数，得确保内核支持 uncore_imc PMU 并启用。常见错误是只用 perf stat -e cache-references,cache-misses——这两个是 CPU core 级缓存抽象指标，不反映 L3 实际行为。
正确做法是显式指定 uncore 事件：
perf stat -e 'uncore_imc/data_reads',\ 'uncore_imc/data_read_misses',\ 'uncore_imc/data_writes',\ 'uncore_imc/data_write_misses' \ ./your_program
注意：uncore_imc 名称因 CPU 厂商和型号而异：
- Intel Skylake 及以后：用
uncore_imc或uncore_cha（CHA 是 Cache Home Agent） - Intel Cascade Lake：需加载
intel_rapl和intel_uncore_frequency内核模块 - AMD EPYC：对应事件是
uncore_pmu/cache_l3_hits和uncore_pmu/cache_l3_misses，但仅在 Linux 5.16+ 支持
命中率 = data_reads - data_read_misses / data_reads（写操作同理，但 L3 write-allocate 行为会让写缺失率失真，优先看读路径）。
立即学习“C++免费学习笔记（深入）”；
用 likwid-perfctr 定位具体 CPU 核心的 L3 访存延迟突增
likwid-perfctr 比 perf 更适合做细粒度延迟归因，尤其当发现某几个核心的 L3 miss rate 明显高于其它核时——这往往不是算法问题，而是 NUMA 绑定或内存访问模式错位导致。
运行命令示例：
likwid-perfctr -C 0-3 -g L3 -m ./your_program
关键输出字段：
-
L3_LAT_DATA_MISS：L3 miss 后到内存的平均延迟（单位 cycle），>200 cycles 通常说明跨 NUMA 节点访问 -
L3_TRANS_ANY：L3 总事务数，结合L3_LAT_DATA_MISS可判断是否大量 miss 都落在远端内存 -
L3_LAT_CACHE_HIT：L3 hit 的延迟，正常应在 30–45 cycles；若 >60 cycles，可能是 LLC 被污染或共享资源争抢（如 AVX 指令挤占带宽）
容易踩的坑：-C 0-3 指定的是逻辑 CPU ID，不是物理核编号；用 lscpu 或 likwid-topology 确认核心与内存控制器的映射关系，否则可能把本地内存访问误判为远端。
通过 pin_memory + mbind 强制数据驻留在本地 NUMA 节点
L3 miss rate 高但 L3_LAT_DATA_MISS 又不高？大概率是数据分配在远端内存、但被频繁访问，导致每次 miss 都触发本地 L3 填充——此时优化重点不是减少 miss，而是让数据“就近落盘”。
典型代码模式：
int numa_node = get_numa_node_for_cpu(0); // 获取 CPU 0 所属 NUMA 节点
void* ptr = mmap(nullptr, size, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB, -1, 0);
mbind(ptr, size, MPOL_BIND, &numa_node, 1, MPOL_MF_MOVE | MPOL_MF_STRICT);必须配合以下设置才生效：
- 开启透明大页：
echo always > /sys/kernel/mm/transparent_hugepage/enabled - 禁用内核自动迁移：
echo 0 > /proc/sys/vm/numa_balancing（否则mbind效果会被覆盖） - 使用
MAP_HUGETLB或预分配并mlock()，避免 page fault 时被调度到远端节点分配
验证是否成功：用 numastat -p $(pidof your_program) 查看 Heap 和 Stack 列是否集中在目标 node；若仍分散，检查是否用了 std::vector 默认分配器——它不尊重 mbind，得换 libnuma 提供的 numa_alloc_onnode。
用 VTune Amplifier 快速识别 false sharing 和 cacheline 伪共享热点
即使 L3 miss rate 正常，程序仍有性能抖动？很可能是多个线程修改同一 cacheline 上不同变量，引发总线广播风暴——perf 看不到这个，因为它不统计 cacheline 级无效化次数。
VTune 的 Memory Access 分析能直接标出：
-
Split_Loads：非对齐访存导致单次读拆成两次，强制跨 cacheline -
LLC_Locations：显示哪些地址被多核高频访问，结合源码定位结构体布局 -
False_Sharing：明确标记出疑似 false sharing 的变量名和汇编行
修复手段简单但易漏：
- 结构体成员按大小倒序排列（大类型在前），减少 padding
- 用
alignas(64)隔离线程私有字段，例如struct alignas(64) ThreadLocal { int counter; }; - 避免在循环中反复取
&vec[i]地址再解引用，改用迭代器或局部指针缓存
最常被忽略的一点：std::atomicstd::atomic<int> a, b;</int> 极可能落在同一 cacheline，必须显式对齐或用 padding。
