LWN：内核热点: folio，多代LRU，以及Rust！

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

The kernel radar: folios, multi-generational LRU, and Rust

By Jonathan Corbet
January 20, 2022
DeepL assisted translation
https://lwn.net/Articles/881675/

内核社区非常繁忙，所以根本无法把所有正在发生的事情都写出完整的文章来介绍。还有其他一些主题可能会引起人们的兴趣，但不需要花很多篇幅来介绍。于是就有了这些短篇主题的集合文章，用来涵盖值得关注的方向的进展。这次我们选择了 folio，multi-generational LRU，以及 Rust in the kernel。

A folio update

自从不到一年前首次报道 folio 以来，它一直是一个活跃话题。回顾一下，folio 只是封装了 struct page 的一个容器，确保这个 page 不会是一个 tail page。因此，它可以用来以 single page 或更大的 page 为单位来指代内存区域。比起直接使用 page 结构来说，拥有更好的类型安全性（type-safe），运行时检查也更加少。经过广泛的讨论之后，第一组 folio patch 被合并到了 5.16 内核中。

对内存管理子系统的这么巨大的改动，自然会导致人们担心出现 regression （质量回退），但 5.16 中合入的这部分似乎没有引发什么问题。因此，5.17 版本中也就有了另一轮与 folio 有关的改动，主要集中在 page cache（用来把文件数据缓存下来）部分。在当前内核中，page cache 中放置的当然是 page 了，但是大多数系统中使用的 4KB page size 通常都太小了，管理效率比较低。在处理那些不是最小 size 的文件时，如果能每次缓存的单位能更加大，那就更有价值了。5.17 中把 page cache 也切换到使用 folio 了，它的目的之一就是允许使用 "large folios"（之所以选择这个名字是因为更清晰的名字 "multi-page folios" 有点太长了）。large folio 可能是 huge page，但并不受 CPU 所支持的那些 huge-page size 的限制。作者的计划是要支持任何 folio size，只要是 2 的幂次就行。

5.17 里的改动对于 page cache、底层文件系统的支持代码，以及 XFS 文件系统中都增加了 large folio 的支持机制，但实际上并没有开始真正使用。正如 Matthew Wilcox 在他的 pull request 中所说："可能还有一些我忽略了的地方仍然会对 page size 有想当然的假设"。因此，会在未来的开发周期中集中寻找这类代码，从而能在 5.18 中实现正式过渡。同时，胆大的人也可以在 5.17 中就启用 large folio 来帮助找到那些遗漏的会导致出错的地方。

The multi-generational LRU

在过去的一年中，有另一个重要的内存管理改动，就是 multi-generational LRU。这个功能对内核在内存紧张时决定抛弃（evict）哪些页面的方式进行了重新的设计。当前内核在使用一个双队列系统，分别用来管理 "active" 和 "inactive" 的 page。所有 page 会根据访问情况在两个队列之间迁移。当需要内存时，会从 inactive 队列的末端来开始回收 page。multi-generational 的改动会把这个机制改为使用更多的队列，这个改动可以让内核更好地识别出哪些 page 是在不久的将来不太可能需要了的。

当 Yu Zhao 在 1 月初发布这组 patch set 的第六版时，他要求大家帮忙 review，并判断是否可以把它合并到 5.17 中。然后引发了对这个功能当前状况的长时间讨论。作为讨论的一部分，Michal Hocko（他也对补丁做了很多详细的 review）重复了一个在以前的回复中中听到过的观点：最好把这项工作看作是一系列渐进的改动，而不要当作是添加一个全新的回收机制：

reclaim 路径上的改动都是不断碰到一些错误情况以及 revert，总是在现有的 fine tuning （微调）基础上继续微调，从而完成的。那些改动跟你的 patch set 的一个主要不同点是，那些改动往往要小得多，一点点递增，因此更容易 review。

Jesse Barnes 回应说，在这个场景中如果使用增量改动方式可能会更糟糕：

我理解人们都希望能看到 "采用一点点增加的方式来让我们完成 A->B"。作为抽象的概念来说，这是个很好的方式。然而对于我们这里看到的改动来说，我认为采用递增修改的方式的话会极有可能出现大大小小的 regression，而且可能比 MGLRU 的相对简洁的设计更难以用推理来调试。此外，我认为我们如果不合入这组 patch 的话，就不会能得到我们所渴望得到的用户反馈。

Linus Torvalds 回复 Barnes 说，这项工作 "值得继续下去"。Hocko 并不反对 Barnes 的观点，但他指出，无论如何，在代码被合并之前还有很多东西需要 fix。

同时，Zhao 一直在积极尝试让这项工作的支持者们在 mailing list 中发声来支持将其合入。回应者包括 Holger Hoffstätte、Shuang Zhai（"性能的提高是难以置信的"）、Suleiman Souhlal（"ChromeOS 上的 Android 已经使用 MGLRU 有一段时间了，效果很好"）、Sofia Trinh、Donald Carr 和 Oleksandr Natalenko。

显然，人们希望合并这个功能。不过，这显然不在 5.17 的计划之内。通常情况下，人们会认为这种根本性的改变会需要很长时间才能实现。但考虑到压力，以及 Torvalds 已经批准，那么这次改动可能比较快。乐观来看 5.18 版本中很可能会包含，总之应该是在 2022 年的某个时刻了。

Rust for Linux

Rust for Linux 项目希望用 Rust 编程语言来开发内核 module，这个工作仍在继续向前推进。1月 17 日的时候发布了 Rust 支持功能第三版 patch set。为了能跟上 Rust 社区的步伐并且使这个功能满足合入要求，其中做了一些修改。

这版 patch set 支持最新的 1.58 版本编译器（也是必须要求要用这个版本）。构建系统现在能够自动确定 Rust 工具链版本是否适合用来 build。发现缺少什么，它就会告诉开发者需要怎么处理。邮件中指出，内核中的 Rust 所依赖的几个之前尚未达到稳定状态的 Rust 功能，在不久的将来会发布的新版编译器中会变成稳定功能。然而，令人沮丧的是，仍然有一个很长的 required unstable feature 清单。

这组 patch set 本身会先增加 "kallsyms" 机制中可管理的符号的最大长度。看起来 Rust 使用的 name 处理机制会让符号名字变得很长，导致 255 个字符对于一些 name 来说都不够了。开发人员通常不用看这些被处理过的名字，但它们会出现在 kallsyms 中，因此这一点还是会让用户感到惊讶的。此外另一个初步步骤是为一长串在内核中看起来像函数的东西添加 C helper function，例如 readb() 或 kmap() 等，这些实际上是 macro 宏或者是 inline 函数。这些功能无法直接从 Rust 中调用，所以需要先把它们转化为正确的函数。

Rust 代码本身目前大多数是位于两个 crate 中。第一个叫做 alloc，用来处理内存分配。Rust 语言在构建时并没有考虑到当内存分配失败时代码可能会需要继续执行下去的需求，因为它以为正常来说应该要马上 crash 才对。由于在内核代码中 crash 被认为是不礼貌的（impolite），所以需要使用能处理这种错误的 allocator 的修改版本。按照 Rust 开发者的期望，它会返回一个 Result 对象，其中包含一个指向所分配内存的指针或一个错误提示，完全取决于分配成功了与否。看起来这些支持会失败的内存分配的功能会要进入 upstream 的 Rust library，所以最终来说内核里面的这个 crate 应该会被移除。

另一个 crate 叫做 kernel。它包含了其余的匹配代码，用来把内核 API 变得看起来像相应的 Rust 接口。包含了 char 设备、clock framework、file structure、file_operations 成员、memory-mapped I/O 函数、mutex、spinlock 等接口。令人惊讶的是，实现通用的 linked list 就用了大量的代码。

总的来说，这一切都是为了实现用 Rust 编写内核代码所做的大量工作。代码相当多，今后需要更广泛地使用，从而来看这些实现是否是沿着正确的方向的。当然，这会有助于把 Rust 支持合入 mainline kernel，让更多的开发者可以看到并使用它。Torvalds 在 2021 年的维护者峰会上表示，他希望把这个功能合入进来，但是暂时还没有迹象表明会在什么时候发生。时间点很可能取决于 Torvalds，在他认为是为这种新语言打开大门的好时机的时候。

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

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

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