2025 年底，我在内核邮件列表里瞥见一个来自 Kiryl 的 series，标题赫然写着：[PATCH 00/11] mm/hugetlb: Eliminate fake head pages from vmemmap optimization
https://lore.kernel.org/all/20251205194351.1646318-1-kas@kernel.org/
目光落上去的瞬间，我便被钉在了原地——"fake head page"，这东西还能被 "eliminate"？它可是我当年在 HVO 的设计中，在内存节省与维护性之间做出的一个工程权衡。如今竟有人找到了绕过这道约束的路径，而且看那架势，是将当年的折中方案整个掀翻。16 files changed, 242 insertions(+), 311 deletions(-)代码净减少七十余行。作为一名社区 maintainer，这红色远不止是红色——那是代码熵值的坍缩，是维护成本的永久性削减。七十行看似不多，但当你意识到这七十行是从一个充满 corner case 的优化路径里砍掉的，那份快意，不亚于从一团乱麻中抽出了那根线头。不过，对于此刻的读者来说，"fake head page" 这个词恐怕还有些陌生。你可能知道什么是 head page。但 HVO——HugeTLB Vmemmap Optimization——这个我数年前向社区提交的特性，以及它为何会催生出那个令人又爱又恨的 "fake head page"，恐怕就不是三言两语能说清的了。若要酣畅淋漓地理解 Kiryl 那一系列 patch 的精妙所在，我们得从头说起。从 Linux 内核为何要为每一页物理内存建立档案说起，从那些被浪费的 struct page 说起，从 HVO 的诞生与代价说起。第一篇，我们从源头出发：Linux 的物理内存模型。唯有先厘清内核如何为每一页内存编址，才能理解 HVO 究竟在哪一处要害下了刀，而 Kiryl 的 patch 又是如何在数年后，将那道旧日刀痕彻底抹平。内存模型：从平坦到稀疏
物理内存如何被编址，不是软件说了算的，而是硬件设计时烙下的底层宿命。最理想的世界里，物理地址从 0 号门牌开始，一路顺延到最高位，不多不少，严丝合缝。遗憾的是，真实硬件从不迁就软件——地址空间里会冷不丁冒出一段谁也访问不了的“黑洞”，也可能被硬生生切割成几块互不相邻的有效区域。更棘手的是 NUMA 架构，内存条各自为政，就近挂在不同的 CPU 身旁，CPU 访存时有的如邻家串门，有的却似千里传书，延迟全看物理距离远近。
这些纷繁复杂的硬件差异，内核不能视而不见，但也绝不能逐案适配。于是，Linux 抽象出了两种内存模型：FLATMEM 和 SPARSEMEM。它们共同的使命只有一个——为每一页物理内存建立一份档案，让内核在任何场景下都能精准定位、高效管理。
而这份档案的载体，便是 `struct page`。无论选用哪种模型，内核都会为每个物理页框维护一个 `struct page` 结构体，记录其状态、引用计数、归属关系等诸多元数据。这是一切内存管理逻辑得以运转的基石。FLATMEM：朴素之美的极致
FLATMEM，人如其名，是所有内存模型中最直白的一种。它适用于非 NUMA 系统，前提是物理内存连续——至少大体上连续，没有太多碍眼的空洞。它的实现思路，朴素到令人心安：内核全局维护一个 `mem_map` 数组，将整块物理内存一股脑映射进来。在大多数体系结构下，即便物理地址空间里藏着无法访问的缺口，这些空洞也会在 `mem_map` 中占据一席之地——对应的 `struct page` 依然存在，只不过它指向的是一页根本不存在的物理内存，像一张有编号却无实物的空头档案。在这种模型下，PFN 与 `struct page` 之间的换算几乎零成本。假设 PFN 从 0 开始编号，那么 PFN 就是 `mem_map` 数组的下标——pfn_to_page() 不过是一次数组索引，是地址偏移量的算术运算。大道至简，莫过于此。但 FLATMEM 的简洁是一把双刃剑。空洞会白白消耗 `struct page` 的内存，而地址跨度过大时，整个 `mem_map` 数组也可能膨胀到难以接受的地步。当物理内存不再规整，FLATMEM 便显得力不从心。SPARSEMEM：辽阔之境的从容
如果说 FLATMEM 是“一把梭”的豪放派，那 SPARSEMEM 就是为混沌场景量身定制的精致方案。它的诞生，正是为了应对那些 FLATMEM 扛不住的局面：物理内存遍布大小不一的空洞、地址跨度动辄以 TB 计、热插拔内存条成为常态。SPARSEMEM 本身又演化出两个分支：CLASSIC SPARSE 和 SPARSE VMEMMAP。在当今主流 64 位系统上，SPARSE VMEMMAP 已是默认选择。我们不妨直入正题，解剖这一方案的精妙所在。SPARSE VMEMMAP 的核心思想，可以概括为四个字：虚拟连续。它在背后藏了一个全局指针 `struct page *vmemmap`，指向一块在虚拟地址空间上完全连续的 `struct page` 数组。注意，是虚拟地址连续——至于物理内存是否真的为每个 `struct page` 都分配了实页，那是另一回事。PFN 依然直接充当数组下标使用，而给定一个 `struct page`，计算它离 `vmemmap` 首地址的偏移量，那偏移量恰恰就是它对应的 PFN。这种计算方式，和 FLATMEM 几乎别无二致，时间复杂度依旧是 O(1)，简洁如初。但区别藏在“虚”与“实”之间。FLATMEM 的 `mem_map` 是虚实一体的——空洞对应的 `struct page` 也实实在在地占着物理内存。而 SPARSE VMEMMAP 只保证虚拟地址连续，对于内存空洞区域，虚拟地址空间里依然留出了对应的 `struct page` 槽位，但不建立物理页映射——换言之，那些槽位只存在于虚空中，并不消耗宝贵的物理内存。在 64 位系统下，虚拟地址空间辽阔如海，这点虚存开销不值一提；而物理内存却被精打细算地省了下来。这便是 SPARSE VMEMMAP 的优雅之处：它保留了 FLATMEM 那种“PFN 即下标”的极致性能，同时又卸下了为空洞保留物理内存的沉重包袱。用虚拟空间的“宽裕”，换取物理空间的“吝啬”，一放一收之间，尽显内核设计者对体系结构的深刻洞察。殊途同归
两种模型，两种哲学。FLATMEM 以简驭繁，安于常态；SPARSEMEM 以巧破局，游走复杂。殊途同归处，是它们对那条铁律的恪守——任你底层虚实交错、地址星散，内核寻一页，始终如叩故人门，一声即应，从不落空。一页千面：head 的丰盈与 tail 的冗余
聊完内存模型如何为每一页物理内存建立 `struct page` 档案，我们得翻开档案本身，看看里面到底写了些什么。`struct page` 是内核中最庞大的数据结构之一，它像一个多面手档案员，记录着页框的状态、引用计数、归属等各种元数据。每个物理页框，无论是否被使用，都对应一个 `struct page`——这是铁律，是内核内存管理一切逻辑得以运转的基石。但 HugeTLB 大页的出现，让事情起了微妙的变化。一个 2MB 的大页，底层是 512 个连续的 4KB 基础页框。这 512 个页框，每一个都有自己的 `struct page`。然而在逻辑上，它们应当被视为一个整体——一个大页，而非 512 页。内核因此引入了复合页（Compound Page）的概念。复合页将一组物理连续的页框捆绑成一个逻辑大页。其中，第一个 `struct page` 被称作 head page，它是团队的领袖，承载着整个大页的主要元数据：阶数（order）、总页数、全局引用计数等。其余 511 个 `struct page` 则被称为 tail pages，它们仅仅是"队员"，大部分字段闲置不用，只保留最基本的存在感。但队员不能不知道自己属于哪个团队。内核利用 tail page 中的某个字段存储了指向 head page 的指针。给定任何一个 tail page，内核都能通过 `compound_head()` 宏快速追溯到头页。这种"认祖归宗"的能力，是内核在大页场景下进行管理的前提。读到这儿，敏锐的读者或许已经嗅到了一丝隐忧：一个 2MB 的大页，需要 512 个 `struct page` 来为其服务，而其中只有 head page 承载着主要的元数据——阶数、引用计数、状态标志，信息密度极高。其余 511 个 tail pages，它们存在的全部意义，不过是充当指向 head page 的 "路标"，让内核在给定任何一个 tail page 时，能够沿着那条指针追溯到真正的管理者。一个指向，仅此而已。用一个完整的 `struct page` ——几十字节的内存——只为存放一个指针，这在信息论的意义上，是一种低效到近乎奢侈的设计。当大页尺寸来到 1GB，背后的 tail pages 数量更是高达 262,143 个，每一个都携带着几乎完全冗余的信息，静默地消耗着物理内存。有没有可能把这些"低密度"的 tail pages 占用的内存释放掉？如果释放了，vmemmap 虚拟地址空间中对应的槽位怎么办？PFN 与 `struct page` 的一一对应关系还能维系吗？这些追问，正是 HVO（HugeTLB Vmemmap Optimization）试图回答的问题。而 HVO 给出了一个完善的解决方案——那是下一篇文章将要讲述的故事。
10个月宝宝每天需要喝多少奶粉？
