LWN：page在2024年的状况！

关注了就能看到更多这么棒的文章哦～

The state of the page in 2024

By Jonathan Corbet
May 15, 2024
LSFMM+BPF
ChatGPT translation
https://lwn.net/Articles/973565/

引入folio结构来描述页面组，是近年来内核中最为基础的转变之一。由于 folio 转换工作影响到了许多子系统，因此在 2024年Linux存储、文件系统、内存管理和BPF峰会的开幕会议上，存储、文件系统和内存管理议题联合讨论了这一主题。Matthew Wilcox 在会议中回顾了这一领域的工作，并讨论了未来的计划。

他首先提到，这一转变的第一步是将传统上存储在内核 page 结构中的大部分信息转移到 folio 中，然后将使用 struct page 的地方都转换为使用新的结构。最初的目标是为复合页 (compound pages) 提供类型安全的表示，但自那以后，任务的目标已经大大扩展。这导致了一些模糊性：在当前内核中，folio 到底是什么？目前来说，folio 仍被定义为“复合页的第一页”。

在下一个阶段完成时，计划是将 struct page 缩小为一个单独的八字节内存描述符，其中最底下几位描述了 page 的类型。描述符本身是跟特定页面类型相关的；例如，slab 页面将有跟匿名 folio 或充满页表条目 (page-table entries) 的页面都不相同的描述符。

推动向描述符转变的主要目标之一是减少内存映射的 size，这是一个描述系统中每个物理页面的规模庞大的 page 结构的数组。目前，内存映射的开销为其所描述内存的 1.6%，这太高了。在使用虚拟化的系统中，内存映射也出现在客户机中，导致内存映射消耗的内存翻倍。通过转向使用描述符，这一开销可以减少到 0.2%的内存，从而在较大系统上节省多达数 GB 的内存。

要达到这一目标，需要将更多信息移入 folio 结构。在此过程中，可以澄清页面的固定计数等概念，清理内存管理子系统中的一些长期问题。这一举措自然会增加 folio 结构的大小，以至于它会大于 struct page 。但优势在于，一个 folio 结构可以指向所有组成这个 folio 的基础页（base page）。对于两个 page 的 folio，总的内存使用大致相同；对于四个 page 或更多 page 的 folio，内存使用量就会减少。如果内核正在缓存一个 1GB 文件，目前需要 16MB 的 page 结构。如果完全用基础页进行缓存，未来这一开销将增加到 23MB。但如果使用四页 folio，则总共下降到 9MB。

某些类型的描述符，包括那些用于slab页面和页表项条目的描述符，已经被引入。页表描述符比 folio 小得多，因为有许多字段是不需要的。例如因为这些页面不能被映射到用户空间，因此不需要一个表示映射次数的计数器。

Wilcox 展示了一张图表，显示自 2021 年以来内核中提到 struct page 和 struct folio 的次数。在这段时间内，大约 30%的用到 page 的地方已经被移除了。他强调，最终目标不是完全去除 struct page ；它总是有其用途的。例如，页面是将内存映射到用户空间的粒度。

自去年的更新以来，内存管理子系统内完成了很多工作。许多内核子系统已经转换为使用 folio。现在还有一种可靠的方法来确定一个 folio 是否是 hugetlbfs 的一部分，之前一直缺乏这个功能，这曾经是一个让人令人惊讶的问题。采用large anonymous folio是一个受欢迎的改动。

虚拟文件系统层也进行了大量与 folio 相关的工作。 sendpage() 回调已被更好的 API 取代。fs-verity子系统现在支持大 folio。buffer cache的转换正在进行中，但遇到了一个意外：Wilcox 假设 buffer head 总是绑定在 folio 上，但事实证明，ext4 文件系统分配了 slab 内存并跟它绑定起来。这种用法并没有错，Wilcox 说，但他“打算使其变成错误”，他不想在此过程中引入错误。

为了避免问题，需要在 struct page 中保留一些本来可能移出的信息。总体来说，他表示，如果早知道会导致这种结果，他就不会在 buffer head 上采取这种改法，但现在他不想退回去重来了。现在一切都很好，他说；ext4 代码非常小心地确保不在非 folio 支持的 buffer head 上调用可能使系统崩溃的函数。但未来没有任何东西可以阻止这种情况发生，这有点令人担忧。

虚拟文件系统层现在通过整个写路径分配和使用大 folio，带来了巨大的性能提升。Wilcox 还添加了一个内部函数，folio_end_read()，对此他颇为自豪。这个函数设置了最新 bit（up-to-date bit），清除了锁定位（lock bit），检查是否有其他线程在等待该 folio，并会作为内存屏障——在 x86 系统上，这些操作都只需一条指令。各种其他辅助函数也已添加，回调函数也进行了更新。还有一个新的回写迭代器（writeback iterator）取代了旧的基于回调的接口；其中一个好处是帮助恢复因 Spectre 缓解措施而失去的一些性能。

各个文件系统中，许多在过去一年里已经转换为 folio。整体上，文件系统正在逃离 writepage() API；因为该 API 被认为是有害的，所以没有创建 folio 版本。bcachefs 文件系统现在可以处理大 folio——几乎没有其他文件系统能做到这一点。旧的 NTFS 文件系统被移除，而不用进行转换。为了支持网络文件系统，创建了"netfs"层。Wilcox 展示了一张图表，显示了许多文件系统的状态，表明大多数文件系统仍有大量工作要做。“XFS 是绿色的，”他告诉在场的开发者，“你的文件系统也可以是绿色的。”

folio 的下一步是将映射（mapping）和索引字段从 struct page 中移出。这些字段可能会在尚不支持大 folio 的文件系统中造成麻烦，而几乎所有文件系统目前都不支持大 folio。与其在转换这些文件系统时冒着引入错误的风险，不如现在就将这些字段移除。同时，许多页面标志（page flags）也正在移出；像 PageDirty 和 PageReferenced 这样的标志是针对整个 folio 的，而不是针对其中的单个页面，因此应保留在 folio 中。还有计划替换仍然直接使用 page 的 write_begin() 和 write_end() 地址空间操作。

除此之外，仍有大量文件系统需要完成转换，其中许多往好里说也是处于“伪维护”状态。hugetlbfs 子系统需要现代化。shmem 和 tmpfs 内存文件系统应该增强，以使用中间大小（intermediate-size）的大 folio。此外，还希望消除所有不使用复合页（compound pages）的大块（higher-order）内存分配，因为这些地方不能直接转换为 folio；加密层有很多这样的分配。

此外，还有“phyr”概念。phyr 是指一个物理页面范围，这是“block 层需要进行的改动”。这将允许块 I/O 操作直接在物理页面上工作，消除对覆盖所有物理内存的内存映射的需求。

看来需要一个 khugepaged 内核线程来将中等大小的 folio 折叠成更大的 folio。其他类型的内存需要为其创建专用的内存描述符。此外，还有KMSAN（Kernel Memory Sanitizer，内核内存清理器），这个工具实际上还没有被认真考虑过。KMSAN 为 struct page 添加了自己的特殊 bit，这种用法需要为基于 folio 的未来重新考虑。

一个重要任务是为更多文件系统添加大 folio 支持。在 Wilcox 所做的转换中，他避免添加这种支持，除了 XFS。这不是一项容易的工作，需要对特定文件系统类型有专业知识。但随着单页 folio 的开销增加，需要使用更大 folio 的需求也将随之增长。大 folio 还有助于减少内存管理子系统的 LRU 列表的大小，从而使回收更加高效。

Ted Ts'o 问到，这种转换对于使用较少的文件系统来说是不是很重要；比如 VFAT 需要转换吗？Wilcox 回答说，对于任何在意性能的文件系统都应该进行转换。Dave Chinner 补充说，任何在 NVMe 固态设备上工作的文件系统都需要大 folio 才能表现良好。Wilcox 总结说，切换到大 folio 使内核编译速度提高了 5%，并且还是人们想要的许多其他功能的前提条件，因此在场的开发人员应该尽早进行转换。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～