LWN：给kernel的swap添加一个抽象层！

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

A new swap abstraction layer for the kernel

By Jonathan Corbet
May 23, 2024
LSFMM+BPF
Gemini-1.5-flash translation
https://lwn.net/Articles/974587/

交换（swapping）在本质上可能是一种内存管理技术，但其实现也涉及内核的文件系统和存储层。因此，在 2024 年 Linux 存储、文件系统、内存管理和 BPF 峰会（2024 Linux Storage, Filesystem, Memory-Management and BPF Summit）上，由 Chris Li 主持的关于内核交换抽象层的会议由这三个领域共同举办也就不足为奇了。Li 对改进子系统有一些雄心勃勃的想法，但要实现可行的方案可能并不容易。

Li 开始介绍了当前内核维护的交换功能的状态开始，以了解新实现需要保留哪些内容。这里的关键数据是交换偏移量（swap offset），即交换文件中可以找到有关已换出页面的其他信息的存储位置。内核中的其他信息都是可选的。他说，这种信息的散布是灵活的，但也可能是痛苦的根源。

当前的交换设计在内存效率方面很高，但很复杂。可以通过使用更多内存来改进它，这实际上相当于为了获得更好的结果而走向更糟的结果。David Hildenbrand 表示，交换层所需的所有资源都是预先分配的，因为在系统需要交换时尝试分配内存很容易失败。这种预分配是为什么非常需要让开销最小化的原因；如果能找到减少预分配的方法，这些开销就不那么令人担忧了。在不使用交换时消耗更少的内存会很好，但当需要交换时必须分配内存就不好了。

Li 同意系统通常情况下不会进行交换；在这种情况下，那些预分配的内存都完全被浪费了。另一方面，当发生大量交换时，交换层中产生的内存高消耗也会造成损害。

他最初提议为每个 交换项（swap entry） 添加一个字节；这用于保存一些标志。完整的交换映射（full swap map，用于跟踪交换设备中空间的使用情况）不会预先分配，而是根据需要进行扩展。但是，添加单个字节的问题是，它会将一个 4 字节项变为 5 字节，这将导致对齐问题。因此，它应该增加 4 个字节，这将允许添加指针。但是，如果添加了 8 个字节，就可能做更多的事情了，包括来动态分配交换项结构。它的 size 可以变化，正如 已针对内存描述符提出的那样。复合交换项可以共享此描述符，最终，这些好处将会让这 8 个额外字节的成本变得很值得。

他说，对直接交换（directly swapping）多尺寸透明巨页 (mTHP) 的支持已添加到 mm-unstable 树中。将 64KB mTHP 交换到 zram 设备可以显着提高压缩率，并节省将单页交换出去时所需的近三分之二的 CPU 时间。但与往常一样，存在代码，主要表现为后端碎片化的增加。随着时间的推移，分配 mTHP 块的能力会下降，以至于即使在不到一半的交换空间使用的情况下，在 5 个小时后也会变得无法使用。

他说，问题在于交换集群（swap cluster）的处理方式。集群 size 设置为等于完整的 THP size（通常为 2MB）。任何单页分配都将从每个 CPU 列表上的第一个集群中获取，导致一个部分为空的集群，该集群不能用于交换即使是 mTHP 大小块（小于完整的 THP 大小）；他不确定为什么。显然需要一个更好的分配器。短期内，他的计划是记录半空的交换集群，并从中分配 mTHP 大小块。长期计划是为交换项创建一个伙伴分配器。

但他表示，更好的分配器还不够。由于交换层不控制交换项的生命周期，因此碎片化仍然会发生。恶意用户可以选择性地释放内存，导致尽管有大量交换空间可用但没有一个可以分配。解决此问题的方法是非连续交换项，由复合交换结构管理。头部项将包含结构的顺序，对于简单情况来说就足够了。更复杂的情况将通过放弃交换空间的对齐要求来处理，并允许它不连续。

Li 指出，这将是一个侵入性的更改。Matthew Wilcox 同意，并警告 Li 说他正在给自己创造“一个痛苦的世界”。Wilcox 说，这个计划是重新发明文件系统，内存管理开发人员试图设计文件系统的悲惨结果是众所周知的。他建议 Li 找到一个文件系统开发人员合作，如果确实需要沿着这条道路走下去的话。

Jan Kara 表示，现有的文件系统设计不适合此任务，因为它们不是为了最小化内存开销而编写的。但他表示，管理这种复杂性将有其成本。他建议，一个更容易的解决方案可能是设置一个最小尺寸，用在交换出去的数据，以此来减少碎片化。他说，大量匿名内存往往不会被使用，因此应该可以将它们以更大的块交换出去，从而减少开销和碎片化。

在会议结束时，Hildenbrand 表示，这个计划引入了太多复杂性。相反，他说，交换进和交换出的粒度应该相互解耦。如果交换空间碎片化是一个问题，那么在交换出去之前，应将 folio 拆分。folio 可以在交换进来时重新组装。Li 回答说，他当前的设计允许部分向内交换（inward swapping）；不必将整个 folio 都换入进来。

和往常一样，下一步将是等待出现实现这些想法的补丁。

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

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