交换表、闪存友好的交换、swap_ops 等

# 交换表、闪存友好的交换、swap_ops 等 来源：https://lwn.net/SubscriberLink/1072657/394b87abd7cc215e/ ## \[LWN 订阅用户专属内容\] > ### 欢迎来到 LWN.net > 以下订阅用户专属内容由一位 LWN 订阅者提供给您。数千名订阅者依赖 LWN 获取 Linux 和自由软件社区的最新新闻。如果您喜欢这篇文章，请考虑[订阅 LWN](https://lwn.net/subscribe/)。感谢您访问 LWN.net！ 内核的交换子系统负责管理匿名页面的二级存储——当这些页面（希望是）未被使用且它们占用的内存被其他地方需要时。这个长期被忽视的子系统近期重新引起了开发者的兴趣，因此在 2026 年 [Linux 存储、文件系统、内存管理和 BPF 峰会](https://events.linuxfoundation.org/lsfmmbpf/) 的内存管理板块中，它成为了三个独立会议的主题也就不足为奇了。其中两个会议关注于提高交换代码的性能和可维护性，而另一个（与存储板块联合）则讨论如何使交换对固态存储设备更友好。 #### 现状与路线图 [![[Kairui Song]](https://static.lwn.net/images/conf/2026/lsfmm/KairuiSong-sm.png)](https://lwn.net/Articles/1072666/) 第一个会议是 Kairui Song 的快速演讲，介绍了交换子系统的最新变化以及未来的发展方向。Song 首先描述了他引入交换表并消除大量交换子系统复杂性的工作；详情请参阅[本文](https://lwn.net/Articles/1056405/)及其[续篇](https://lwn.net/Articles/1057102/)。在他的改动合并到 7.0 版本之前，交换子系统的开销为每页 3 到 11 字节；现在这个开销已降低到 2 到 10 字节。这一消息赢得了与会者的掌声。 不过 Song 并未止步；他打算将静态开销降至零字节，但最大仍为 10 字节。他计划将开销上限控制在 8 字节，但短期内无法实现，因为[内存资源控制器](https://docs.kernel.org/admin-guide/cgroup-v1/memory.html) 的 refault 追踪需要更多数据。长期来看，他仍希望将最大开销降至每页 3 字节。 某些操作绕过交换缓存的需求已被消除，大多数面向交换的辅助函数现已基于 folio。现在大多数操作只需持有 folio 锁；他表示，可以通过应用一些无锁算法进一步优化。将 folio 分配与交换缓存统一的工作仍在进行中。目前，匿名和共享内存 folio 有自己的分配逻辑，可能会绕过预读取；他将这段代码描述为一个冗长、复杂且充满竞态的后备循环。他正致力于用一个统一的分配辅助函数来替代它。 其他工作旨在让系统更好地利用交换缓存；更好的预读取支持是这方面的重要一步。[zram 子系统](https://docs.kernel.org/admin-guide/blockdev/zram.html) 现在可以从中受益，但他说，这是否有益尚不完全明确。也许 zram 本身已经足够快了。 交换 I/O 是异步且耗时的；这意味着从内存压力出现到 I/O 完成（释放压力）之间可能存在较长的延迟。到那时，系统可能已经过度换出，比实际需要换出了更多的页面。这可以通过在写回完成后立即从交换缓存中丢弃页面来改善。他不确定为什么现在没有总是这样做；这需要进一步研究。 还有许多其他问题亟待解决。PMD 级别的透明大页的交换效率还不够高。预读取可能会带入用于休眠的页面，这虽然浪费但问题不大，然而其解决方法并不美观。他正在考虑添加一个特殊位来标记为休眠保留的页面。有些用户希望能够动态调整交换区的大小；现在应该已经可以实现这一功能。 另一个问题出现在匿名和共享内存（shmfs）folio 交换到同一设备时。如果基于 shmfs 的透明大页正在被交换，它们可能会与匿名页的槽位重叠；目前当这种情况发生时，有问题的 folio 会被直接丢弃。然而，如果预读取支持透明大页，问题会变得更严重。他正在考虑创建一种新的交换表类型来解决这个问题。Matthew Wilcox 表示，问题可能源于逻辑（在拥有进程的地址空间内）和物理预读取的混淆；他认为我们在某个地方做错了事。 Song 正在研究交换表的压缩。系统以集群为单位管理交换空间，这些集群被组织成一个最近最少使用列表。可能可以将满的集群从列表中移除；这可以提高性能，但可能会增加内存压力。 以上所有内容压缩在半小时内完成，但 Song 还没有结束。他说，是时候将“交换文件”重命名为“交换映射”了。现在的交换看起来很像文件支持内存的映射，尽管具有不同的写回策略和锁机制。通过添加一个新的虚拟交换层，可以将其中大部分抽象出来，这也能解决许多其他问题（如碎片整理和迁移）。他展示了一张幻灯片，展示了这一层的整体设计： > 虚拟交换层设计 一个 [RFC 补丁集](https://lwn.net/ml/all/[email protected]/) 已经发布，包含了这一想法的初始实现。它重用了现有的交换基础设施，但增加了一个额外的映射层。除其他外，这种设计允许更快地移除交换设备（因为不再需要调整所有拥有该设备上页面的进程的页表项），并方便地实现交换设备的碎片整理。 Johannes Weiner 指出，这种设计可以更容易地换出大页，而无需在交换设备上要求连续的大块空间。David Hildenbrand 询问虚拟表会有多大，以及是否会出现碎片化问题；Song 回答，表可以做得足够大以避免此问题。 #### 闪存友好的交换 [![[Youngjun Park]](https://static.lwn.net/images/conf/2026/lsfmm/YoungjunPark-sm.png)](https://lwn.net/Articles/1072676/) 交换会产生大量 I/O，如果管理不当，会显著缩短固态存储设备的使用寿命。Youngjun Park 正在研究积极使用交换的嵌入式设备，他希望这些设备不会过早耗尽交换存储空间。本次会议是内存管理和存储板块的联合会议。 他说，闪存会随着时间磨损。数据重写会导致擦除循环，因此向设备拷贝数据会带来额外的写入和磨损。内置的闪存转换层（FTL）具有一定程度的磨损均衡支持，但还不够，结果就是交换对闪存设备造成很大压力。它产生持续不断的随机 4KB 操作，给磨损均衡算法带来挑战，但友好闪存的写模式是存在的，并且可以用上。 所述嵌入式设备使用一种类似 zram 的自定义机制将数据交换到 RAM，在内存中对页面进行压缩。这些页面由一个注册为回收器的内核线程刷新到持久存储；它执行与擦除块对齐的顺序写入。还有一个去重层可以减少写操作；特别是，有很多页面与之前休眠轮次中保存的页面匹配，无需重新写入。他说，结果是存储设备的寿命大大延长。 Christoph Hellwig 请 Park 分享他的代码，“即使它很丑”；这有助于其他人理解情况。Park 回答，它是作为块设备实现的，难以合入主线；Hellwig 说，关键不是合入代码，而是推动讨论。他说，里面有一些好想法；代码可能需要进行重大重构，但有一个可用的起点会很有帮助。 Weiner 问 Park 是否考虑过使用 [zswap](https://docs.kernel.org/admin-guide/mm/zswap.html) 并增加某种写回功能。回答是考虑过这个选项，但（因未说明的原因）没有采用。Wilcox 说，他发现所描述的方法令人惊讶，覆盖整个擦除块通常效果更好。Chris Li 评论说，很难发现描述特定设备最优 I/O 模式的参数，他希望鼓励供应商更自由地提供这些信息。 最后一部分讨论集中在 Park 的系统严重依赖休眠上，这就是大量交换流量的来源。有人建议，也许更好的做法是将交换和休眠解耦，并使其能够创建一个独立的休眠目标，该目标仍使用交换设备，但会避开交换代码及其 I/O 模式。 #### 抽象化交换后端 交换子系统设计为直接与块设备接口，并在内部创建其块 I/O 操作。然而，人们有兴趣在交换子系统的存储层放置其他类型的设备。这一概念被称为“swap_ops”，由 Baoquan He 提出[讨论](https://lwn.net/ml/linux-mm/aZiFvzlBJiYBUDre@MiWiFi-R3L-srv/)，但正如 Li 在会议中解释的，He 因 [Red Hat 关闭其整个中国开发团队](https://www.theregister.com/software/2026/04/10/red-hat-rhelocates-its-chinese-engineering-team-to-india/5222097) 而受影响，因此 Li 将主持讨论。 他首先说，swap_ops 的核心思想是成为一个子系统，支持模块化的交换后端，并允许自定义某些交换行为。他说，这将是交换的虚拟文件系统（VFS）层。这一想法最早在 2023 年的 LSFMM+BPF 会议上被[提出](https://lwn.net/Articles/932077/)，并在 [2024](https://lwn.net/Articles/982887/) 和 [2025](https://lwn.net/Articles/1016136/) 年进一步讨论。它与 VFS 有许多相似之处；例如，VFS 在文件系统开头有超级块，而交换层则有交换头。VFS 中的文件很像交换子系统中的 folio，inode 类似于交换条目，等等。但 swap_ops 层的开销要低得多，并且不支持与目录对应的概念。 Li 说，有一个补丁系列实现了这一概念；He 在 5 月 12 日[更新了该系列](https://lwn.net/ml/all/[email protected]/)。作为其价值的例子，Li 指出 zram 子系统当前在模拟块设备；如果 zram 作为 swap_ops 后端实现，将可以移除大量代码。其他可能的后端可以是像 Park 描述的那种闪存友好层，甚至可以是直接操作原始闪存的后端，尽管与会者对那个想法并不热情。最终还可以添加对压缩页面 I/O 的支持。 最后，Li 说，允许后端处理交换槽位的分配可能是有意义的。还需要研究如何在后端之间移动页面的最佳方式。Li 就此结束，小组没有提出问题。 本文索引条目 Kernel (https://lwn.net/Kernel/Index) Memory management/Swapping (https://lwn.net/Kernel/Index#Memory_management-Swapping) Conference (https://lwn.net/Archives/ConferenceIndex/) Storage, Filesystem, Memory-Management and BPF Summit/2026 (https://lwn.net/Archives/ConferenceIndex/#Storage_Filesystem_Memory-Management_and_BPF_Summit-2026)