perf可定位真实访存延迟与带宽瓶颈：用mem_load_retired.l3_miss占比>15%判定DRAM拖慢，配合perf record -g和likwid-perfctr测带宽，绑定NUMA节点、禁用透明大页、慎用clflushopt，并以-O2 -march=native编译确保测量准确。
用 perf 抓取真实访存延迟和带宽瓶颈点
Linux 下最直接的方式不是看理论峰值，而是用 perf 观测硬件级事件。关键不是“CPU 忙不忙”，而是“它在等内存等多久”。perf stat -e cycles,instructions,cache-misses,mem-loads,mem-stores,l1d.replacement 能暴露 L1D 压力；但真正定位延迟瓶颈，得加 mem_load_retired.l3_miss 和 cycles:u（用户态周期）对比——如果 mem_load_retired.l3_miss 占总周期比例 >15%，基本可断定是 DRAM 访问拖慢了。
常见错误：只跑 perf stat -B 看平均值，忽略分布。实际中应配合 perf record -e mem_load_retired.l3_miss -g + perf report 定位到具体函数/循环体，尤其注意编译器是否把访存合并或重排了。
- 必须用
-O2 -march=native编译，否则perf捕获的指令流和真实运行不符 -
mem_load_retired.l3_miss在 Intel Skylake+ 上可用，老 CPU 用offcore_response.all_data_rd.any_response替代（但噪声大） - 避免在容器或虚拟机里测——
perf的 PMU 事件可能被截断或统计失真
用 likwid-perfctr 验证内存带宽是否打满
理论带宽 ≠ 实际吞吐。likwid-perfctr -C 0-3 -g MEM -f ./your_app 可直接输出 MEM bandwidth [MByte/s] 和 MEM data volume [MByte]，比 stream 工具更贴近真实负载模式。重点看两个比值：MEM bandwidth / theoretical peak 若 MEM data volume / L3 size 若 > 2，说明工作集远超缓存容量，必然频繁刷写 L3。
容易踩的坑：默认 likwid-perfctr 测的是所有核共享的内存控制器带宽，但 NUMA 节点间跨片访问（如 Node 0 的 CPU 访 Node 1 的内存）会显著拉低有效带宽。务必用 numactl --membind=0 --cpunodebind=0 绑定后重测。
立即学习“C++免费学习笔记（深入）”；
- 确认当前 CPU 支持的内存通道数：
lscpu | grep "NUMA node.*CPU(s)"+dmidecode -t memory | grep "Speed\|Width" - 若实测带宽卡在单通道水平（比如 DDR4-3200 × 1 = ~25 GB/s），检查 BIOS 是否启用了多通道模式，以及内存条是否插在正确插槽
-
likwid-perfctr的MEM组不包含预取干扰，但若代码含大量__builtin_prefetch，需关掉再对比
用 __builtin_ia32_clflushopt 和 _mm_mfence 控制缓存污染
很多 C++ 程序员以为“清缓存”就是 std::memset，其实那只是改数据，没清 cache line。真要测冷启动延迟或排除缓存干扰，得用硬件指令：__builtin_ia32_clflushopt((char*)ptr) 刷指定地址，配合 _mm_mfence() 保证顺序。但滥用会导致性能雪崩——每次刷 64 字节，若循环刷整个数组，L3 带宽全耗在这上面。
典型场景：微基准测试（如测单次 mov 到未缓存地址的延迟）必须清；但生产代码里，除非你在做加密密钥擦除或敏感数据归零，否则不要主动 flush。
- 用
clflushopt前先mmap(MAP_POPULATE)分配内存，避免 page fault 干扰测量 - Clflush 后立刻读同一地址，会触发 cache miss，延迟 ≈ 100+ ns（DDR4），这正是你要测的“真实访存延迟”
- ARM 上对应的是
__builtin_arm_dc_cvac+__builtin_arm_isb，不能混用
调整 vm.swappiness 和透明大页对延迟敏感型程序的影响
即使你没开 swap，vm.swappiness=60（默认）也会让内核积极回收匿名页，导致 TLB miss 暴增、页表遍历变慢。对低延迟 C++ 服务（如高频交易、实时音频），应设为 1 或 0；同时禁用透明大页：echo never > /sys/kernel/mm/transparent_hugepage/enabled，否则 mmap 分配的内存可能被拆成 2MB 大页，而小对象分配器（如 jemalloc）无法高效管理，造成内部碎片和首次访问延迟突增。
验证方式：用 cat /proc/self/smaps | grep -i "mmu|thp" 查看进程是否真的用了 THP；用 perf record -e 'syscalls:sys_enter_mmap' -g 看 mmap 是否触发了大页折叠。
- 修改
vm.swappiness后，需重启应用进程才生效（内核不会 retroactively 调整已有页的回收倾向） - 若程序用
mlock()锁住关键内存，vm.swappiness影响变小，但 THP 仍可能导致锁页失败（ENOMEM） - 某些云厂商的 kernel patch 会绕过
transparent_hugepage=never，此时需检查/sys/kernel/mm/transparent_hugepage/defrag是否也设为never
真正的瓶颈从来不在纸面参数里，而在 perf report 的火焰图顶部、likwid 输出里那个低于预期 30% 的带宽数字、以及你忘了关掉的透明大页开关上。
