TLB miss在高频交易中代价极高，因单次缺失耗时超100周期，远超订单处理总周期；需用大页、内存池化、禁用ASLR与THP等综合优化。
TLB miss 在高频交易里为什么特别疼
因为一次 TLB miss 可能吃掉 100+ 周期，而一笔订单从网卡进来到发出可能只跑几百个周期——TLB 缺失直接打断流水线，且无法被 CPU 预测器掩盖。内核态下更糟：每次系统调用（比如 recvfrom 或 sendto）都可能触发页表遍历，尤其当应用频繁切换收发缓冲区或使用非连续内存时。
用大页（Huge Pages）绕过二级页表查找
标准 4KB 页在 x86-64 下需 4 级页表遍历；2MB 大页只需 3 级，1GB 页仅需 2 级。TLB 条目复用率飙升，miss 率可降 5–10 倍。
- 必须在启动前分配：用
echo 2048 > /proc/sys/vm/nr_hugepages预留 2MB 大页（数值按实际 buffer 数×单 buffer 大小 / 2MB 计算） - 用户态申请要显式指定：
mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB, -1, 0)，漏掉MAP_HUGETLB会静默退化为普通页 - 检查是否生效：
cat /proc/meminfo | grep HugePages看HugePages_Free是否减少；用perf stat -e dTLB-load-misses对比前后数据 - 注意：内核 4.16+ 支持
MAP_HUGE_2MB等 flag，旧内核只能靠MAP_HUGETLB+ sysctl 配置
避免内核态地址空间碎片导致 TLB 冲突
高频程序常反复 mmap/munmap 小块内存（如 per-order 消息 buffer），内核 vma 链表碎片化后，即使物理页连续，虚拟地址也可能分散，挤占 TLB 容量。
- 统一用池化分配：预分配一大块
mmap区域（带MAP_NORESERVE减少 commit 开销），运行时用位图管理子块，杜绝频繁 syscall - 禁用 ASLR：启动前
echo 0 > /proc/sys/kernel/randomize_va_space，确保每次加载的 mmap 基址稳定，TLB 条目复用率更高 - 避免
mremap扩容：它大概率触发新虚拟地址分配，TLB 条目失效；宁可预估上限一次性 mmap
内核参数调优：减少页表更新开销
即使用了大页，内核仍可能因 COW、swap、page migration 触发页表项修改，引发 TLB shootdown —— 多核间广播 TLB flush，延迟远超本地 miss。
立即学习“C++免费学习笔记（深入）”；
- 关掉透明大页（THP）：
echo never > /sys/kernel/mm/transparent_hugepage/enabled，THP 的后台折叠逻辑会干扰你手动管理的大页布局 - 禁用 swap：
swapoff -a，避免 page reclaim 修改页表项；高频进程应mlockall(MCL_CURRENT|MCL_FUTURE)锁住内存，防止换出 - 调低
/proc/sys/vm/swappiness到 0，进一步抑制内核主动回收匿名页
真正难的不是配几个参数，而是确认你的内存访问模式确实局部性足够强——如果 buffer 大小忽大忽小、生命周期错乱，或者混用大量不同大小的 mmap 区域，大页和 TLB 优化全白搭。先用 perf record -e tlb_flush 看 flush 频次，再决定动不动内核参数。
