Linux内核为何默认不使用大页？大页必用场景有哪些？

你观察到的默认nr_hugepages=0、内核普通mmap逻辑不用MAP_HUGETLB标志，本质是通用场景下的权衡设计，完全不代表内核不需要大页。

默认配置不预留静态大页的原因 #

你接触到的MAP_HUGETLB标志、/proc/sys/vm/nr_hugepages参数，对应的是Linux的**静态预留大页（Hugetlbfs大页）**机制，这类大页有几个硬特性：

• 必须在系统启动后/运行时提前预留，预留后这部分内存就从普通伙伴系统分配器里划走，普通4KB页的内存申请完全不能征用
• 预留的大页默认不支持swap，不会被页回收机制回收
• 分配逻辑严格，申请长度不对、大页剩余不足时直接返回错误，不会自动回退到普通页

对于通用场景（普通桌面、轻量云服务器、日常业务应用）来说，大部分进程的内存访问局部性不强，TLB miss优化带来的性能收益远抵不上静态预留大页造成的内存利用率损失——如果默认预留几百MB甚至几GB大页，普通进程用不上就完全浪费，还可能导致普通应用内存不足触发OOM，所以默认把nr_hugepages设为0是面向绝大多数使用场景的合理选择。
另外你看到内核内部的mmap实现没有加MAP_HUGETLB标志也很正常：MAP_HUGETLB是给用户态进程申请大页暴露的接口标志，内核自身的内存映射根本不走这套用户态接口的逻辑。

内核本身对大页的使用 #

内核不仅用大页，而且从系统启动阶段就尽可能用大页，完全不需要依赖上述的静态大页机制：

• 内核的线性地址空间（直接映射所有物理内存的区域）在页表初始化阶段就会优先用1GB大页、其次2MB大页做映射，根本不会拆成4KB小页，这部分映射的TLB命中率几乎是100%，你可以在系统dmesg日志里找到类似Kernel direct mapping uses 1GB pages的打印记录
• 对于用户态进程的匿名内存、页缓存，内核默认开启**透明巨页（THP, Transparent Huge Pages）**机制，不需要用户程序传任何特殊标志、也不需要提前预留大页，内核后台会自动把符合对齐要求、访问频繁的连续4KB页合并成2MB大页，遇到内存压力、内存访问模式不适合大页的时候还会自动拆回小页，对应用层完全透明。绝大多数场景下你感受到的大页性能收益，其实都是THP在默默工作，根本不需要手动配置静态大页。

必须显式使用静态大页的场景 #

THP虽然对通用场景友好，但它的动态合并、拆分逻辑会带来不可控的延迟抖动，而且大页粒度默认只支持2MB，以下场景必须用MAP_HUGETLB接口配合提前预留的静态大页（甚至1GB粒度大页）才能满足要求：

• 高性能计算（HPC）、大规模数值计算场景：这类应用通常占用几十GB到TB级内存，全程对大数组做连续/随机访问，THP的后台合并开销、偶发的拆页操作会带来明显的性能波动，静态大页可以把TLB miss率降到最低，性能稳定无抖动
• 低延迟基础设施场景：比如DPDK用户态网络转发、Redis缓存、高频交易系统，这类应用对亚毫秒级的延迟尖刺零容忍，THP的后台整理、页拆分持锁逻辑会导致请求延迟突增，静态大页提前分配锁定、无运行时开销，是这类场景的标准配置
• 虚拟化设备直通场景：QEMU/KVM给虚拟机分配内存、搭配VFIO做PCIe设备直通时，必须用静态大页锁定虚拟机内存，避免宿主机内存回收、页表拆分导致DMA访问错误，同时还能降低嵌套页表的TLB开销，提升虚拟机IO性能
• 硬实时系统场景：实时任务对运行时的执行时间确定性要求极高，THP带来的不可控内核开销完全不能接受，必须用静态预留的大页锁定所有工作内存，杜绝所有运行时内存管理带来的延迟干扰

用户态申请静态大页的参考代码 #

注意原示例代码里直接用getpagesize()是有坑的：该接口默认返回普通4KB页的大小，申请大页时需要对齐到实际使用的大页粒度（比如2MB/1GB），否则会触发mmap报错：

// 示例：申请4个2MB粒度的静态大页，长度对齐到2MB
#define HUGEPAGE_2M (2 * 1024 * 1024)
void *hugepage = mmap(0, HUGEPAGE_2M * 4, PROT_WRITE | PROT_READ,
                    MAP_ANON | MAP_HUGETLB | MAP_PRIVATE, 0, 0);
if (hugepage == MAP_FAILED) {
    // 处理大页不足、权限不足的错误
}

内容的提问来源于stack exchange，提问作者noha