LWN: folio 改动未能合入！

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

The folio pull-request pushback

By Jonathan Corbet
September 10, 2021
DeepL assisted translation
https://lwn.net/Articles/868598/

在我们上次介绍 page folio 的时候，当时看来它有望在 5.15 合并窗口期间被合入 mainline。Matthew Wilcox 在 8 月份正式发出了一个 pull request，希望能合入 mainline。虽然 folio 仍有可能被合入到 5.15 版本，但截至目前还没有达成这个目标，并且可能性越来越小了。我们只看到关于 folio 方案价值的长长的讨论。

内核中内存管理子系统是以 page 为单位来管理内存的，这个基本单位通常由硬件决定（一般是 4KB 大小）。不过这些 "base" page 非常小，内核经常需要以更大的单位来处理内存。为此，它将一些在物理上连续的 page 组合成 compound page，它们都是由一个 head page（指 compound page 复合页中的第一个 base page）和一些 tail page 组成的。这就导致了这样一种情况：内核代码收到一个 struct page 的指针时，如果不仔细检查一下的话，就无法知道它在处理的是 head page 还是 tail page。

事实证明，在代码中加上 "确保这是一个 head page" 的检查在内核运行时增加了一些开销。并且内核中到处都在使用 struct page，也使得内核的 API 变的有些不明确，因为很难知道某个函数是否能够处理 tail page。为了解决这个问题，Wilcox 创造了 "folio" 的概念，它就跟一个 struct page 很像，但可以确定的是它绝对不会是一个 tail page。通过改变 kernel 内部的函数来使用 folio 结构，Wilcox 提升了内核的运行速度，并且同时让 API 更加清晰了。这个 patch set 是非常巨大的，到处都在进行修改（intrusive），但之前似乎已经克服了大多数阻碍，做好进入 mainline kernel 的准备了。

Objections

内存管理开发人员 Johannes Weiner 很快地回复了这个 pull request，他对 folio 这个概念表示 "strong reservations"。在后续讨论中，他把自己的反对意见用多种方式讲述了出来，但似乎都归结为一个核心问题：folio 只是一个物理上连续 page 的集合，这将使它难以处理内存管理所面临的一些挑战。

首先，folio 的设计泄露了太多内存管理方面的内部信息给其他那些使用了 folio 结构的子系统，尤其是在文件系统子系统中更是如此。当然，目前使用 page 结构的 API 也有同样的问题，但他说，大规模的 API 变动正好是解决这个问题的时机。因此，Weiner 多次要求创建一个更抽象的内存描述方式，用来供内核的更高层次的模块使用。这种抽象可以隐藏很多细节，并且 folio 现有的物理连续、2次方 size 内存块的这些假设条件也可以被消除了。

他继续说道，物理连续的这个前提条件是一个严重问题，因为内存管理子系统从来都不擅长分配较大的、连续的内存块。在某些场景中，系统中大多数内存都碎片化了，找不到更大的连续内存块了。像 page compaction 这类技术可以在一定程度上有所帮助，但它的代码就是带来更高的分配延迟。他说：“事实上我们在这方面已经宣告失败了。”在不解决分配这些大块连续区域的情况下，光采用 folio 来表示更大的内存连续区域就是没有意义的。

他说的另一个问题是 folio 的概念可能会使今后改动内存管理子系统来使用更大的 base page size 变得更加困难。这种改动会使系统在许多方面更加有效率，比如减少浪费在 struct page 上的内存，以及减少用于处理这些结构的 CPU 时间。但是，有一个问题导致内核多年来一直没有增加 base-page size：internal fragmentation（内部碎片化）。

当一个文件的内容（或其一部分）被存储在 page cache 中时，就需要一定数量的完整 page。类似 Unix 这样的系统有很多小文件，但即使是一个几个字符的文件也会在 page cache 中占据一个完整的 page。该 page 中文件末尾的内存全都被直接浪费了。增加 base page 的大小必然也会导致因这种内部碎片而损失的内存数量变得更多。在以前的一个讨论中，Al Viro 做了一个快速计算，说明在更大的 page size 下要保持内核源代码都在内存里的话需要多少内存。例如，64KB 的大小将使要用到的内存 size 翻两番。这个代价不算小了。

出于这个原因，Weiner 认为，即使内存管理子系统后续转向更大的 base-page size，内核也需要能够以小的单位（例如现有的 4KB 大小）来进行 file caching。换句话说，page cache 需要能够使用内存中比 page 更小的单位来进行工作。因此这里如果能使用新的内存抽象的话可能会促进这一点。而目前的 folio 概念则由于与底层 page 牢牢地联系在一起，因此无法有所帮助。

Wilcox 对这个反对意见的回答似乎是说，使用不同于 allocation size 的单位来管理内存的话并没有什么好处。因此，在内存管理子系统中使用较大单位页面的方法就是分配 compound page，并用 folio 来代表之。如果内核中的所有内容都使用较大的 page，内存碎片就会减少，这些 page 也就会更容易分配出来。对于需要较小 page size 的场景，例如小文件的 page-cache entry 项，就可以直接使用 base page。通过仔细进行分配，就可以让这些单独的 page 可以 pack 起来，进一步避免了碎片化。

但是，Weiner 不同意这种方法，他认为这把避免碎片的责任归结给了错误的地方。内核的内存分配有两个层次：page allocator（这里处理单位是完整 page，也就是 folio 相关的地方）和 slab allocator（通常用来处理较小单位的内存分配）。它们优势不同：

page allocator 擅长分配统一的（uniform）、较大的内存区域。slab allocator 擅长将这些区域细分为更小的对象，做好整齐的 pack 和 group 管理工作来方便后续回收成连续内存，同时向用户空间和内核空间的开发者提供了每种内存使用情况以及内部碎片的详细划分。

据 Weiner 说，Wilcox 的方法让 page allocator 来处理目前在 slab allocator 中已经很好地解决了的问题。"如果这就是你希望 folio 后续做的事情，那么很抱歉，我只能回复 NAK"。

The real problem with folios

当然，是否合并 folio，最终决定是由 Linus Torvalds 决定的。在讨论的早期，他对 API 的改进给予了肯定，但也指出，这组 patch set 确实给内存管理子系统带来了大量干扰。他总结说 "所以我并不讨厌这些 patch。我认为它们很聪明，很可能是值得的，但我也肯定是不喜欢它们的。"

然而，他也指出，他对 "folio" 这个名字并不是很满意，这就又来到了内核社区讨论中一个经常出现的规律：当技术问题讨论很深入并难以解决的时候，一定会开始对 name 进行扩展辩论了。所以 David Howells 建议用 "sheaf" 或 "ream"。Torvalds 则倾向于更直接的描述性的东西，比如 "head_page"。Ted Ts'o 认为 "mempages" 也可以，或者是 "pageset"。Nicholas Piggin 赞成 "cluster" 或 "superpage"。在讨论之后，Vlastimil Babka 总结下来唯一合适的名字是 "pageshed"。

Wilcox 已经说得很清楚了，他并不关心这个名字是什么，只要能把代码合入进去，他几乎可以接受任何名字。他重做了 pull request，把所有地方都重命名为 "pageset"，就证明了这一点。不出意料，这个分支讨论并没有得出什么真正的结论。

8 月底的时候，Howells 发文请求尽快解决这个问题，因为还有很多其他有待解决的内存管理工作，它们要么依赖于 folio patch，要么与之冲突。他问道：

是否有可能按原样直接接受 folios patch set 并接受这个名字，或者只接受 Willy 的重命名之后的版本（尽管它还没有经过 linux-next 的验证）？还是说这个方法有着根本性的缺陷，需要重做？

David Hildenbrand 补充说，他希望看到 folios 能以任何方式从 linux-next 中移出去，越早越好。

Now what?

现在看来对话已经结束了。5.15 合并窗口已经接近尾声，而 Folio patch 还没有被合入。这意味着，folio patch set 最起码也得再等待一个开发周期了。Torvalds 有时候会将有争议的 patch 保留到（甚至超过）合并窗口的结束时间点，那时会有更多的时间来考虑。因此，即使是合并窗口关闭了，也不意味着他已经作出了决定。

最后结果还没有出现，但无论如何很明显的是，在内存管理子系统中还有很多工作要做。很多需要进行的改动还没有被设计出来，更不用说编写代码和调试了。这为 Wilcox 的最后一个论点增加了一些支持。"Folio patch 现在已经是个现成版本了"。或者，正如 Babka 问到的："我们是否应该什么都不做，一直到有人真正把这个假设中的未来变成真实代码，然后我们再看它是否有效？" 如果 folio 的代码被抛弃了，那么基于它进行的对内存管理内部进行的改进工作将不得不从头开始，而目前还看不出有什么人准备好了要接受这一挑战。

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

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

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