深入Linux 内核：解决 Linux 透明大页在内存不足时导致的系统卡顿问题

把transparent_hugepage/enabled从madvise调成always,本想让大页多吃一点,线上 p99 反而涨了两三倍。于是团队记下一条经验:THP 有害,关掉。这条经验错在,它把账算到了大页头上。

账其实很好算,而且几乎总是划算:一个 2MB 大页顶 512 个 4KB 页,TLB 覆盖范围涨 512 倍、页表内存省 512 倍——这些收益是真的,几乎从不失手。真正让 THP 在延迟敏感的大内存服务上翻车的,不是大页本身,而是它把「缺页 → buddy 分配 → 回收 → 内存整理」这条平时各干各的慢路径,在一次缺页里串成了一根同步链条。所以该拧的旋钮从来不是always还是madvise,而是defrag和回收水位线;拧错了对象,才是 p99 翻车的真正原因。

缺页不是一个局部事件:从硬件页表走查失败说起

一个进程访问一个还没落到物理页的虚拟地址,CPU 的 MMU 会自己走一遍页表——x86-64 上是四级(开了 5-level paging 是五级):PGD → PUD → PMD → PTE,每一级是一次依赖性的内存加载,前一级的内容决定下一级去哪读,四次访问严格串行、没法并行掩盖。末级那个 PTE 里如果 present 位是 0,MMU 放弃,产生#PF异常。到这里都还是硬件的事;从这一刻起,内核接手。

为什么 TLB 这么金贵,值得为它开大页?因为这四次串行内存访问,即便命中 cache 也是几十