Transparent Huge Pages：大页能省 TLB，为什么有时又会卡顿？

操作系统通常以“页”为单位管理内存。普通页尺寸较小，精细灵活，却意味着大内存工作集可能需要很多页表条目和地址转换。Transparent Huge Pages（THP，透明大页）尝试把一组相邻普通页合并为更大的映射，让处理器用更少的 TLB 条目覆盖更多内存，也有机会减少页表层级和管理负担。

“透明”指应用程序通常不必改成另一套内存 API，内核可以在合适的时候尝试使用较大的页。可以把它想成把许多小储物格合并成大柜子：找东西时索引更少，管理结构也可能更精简。对持续访问大块内存的负载，这有机会减少 TLB 未命中和页表开销。它并非对所有程序都必然加速，而是操作系统与工作负载共同决定的优化机会。

大页的另一面是粒度变粗。需要分配或清零更大块内存时，单次缺页处理可能更重；物理内存碎片也可能让内核难以找到合适的连续空间。若应用只改动大页中的很小一部分，复制或写时拆分可能增加额外工作。对延迟敏感的服务，偶发的内存整理、合并或缺页成本，可能比平均吞吐量更值得关注。

THP 与显式 HugeTLB 大页也不是一回事。前者强调内核透明地尝试合并和回退，通常可以在条件不合适时继续使用普通页；后者则是应用或管理员明确申请、管理的大页资源。透明不等于“内核永远会成功”，更不等于“所有进程都应该开启”。内核提供了不同策略和监控接口，实际行为还受系统配置、内存压力与内核版本影响。

评估时应使用接近真实的负载，分别看吞吐、尾延迟、内存占用、缺页情况和碎片整理影响。只跑短小合成测试，可能看见 TLB 收益，却错过长时间运行后的抖动。若工作集很小，或访问模式并未受 TLB 限制，大页的收益可能有限；若负载规模大、访问密集，才值得进一步验证。对线上系统，先在隔离环境逐步测试，并保留回退路径。

THP 的价值不在于“大就是快”，而在于用更粗的页粒度换取地址转换效率，同时接受分配和管理成本。这是操作系统中很典型的工程权衡：自动优化减少应用改造，却仍需要用实际负载验证。

来源：Linux 内核文档：Transparent Hugepage Support