LWN：重新审视多代 LRU

关注了就能看到更多这么棒的文章哦Jonathan CorbetGemini translation原文链接https://lwn.net/Articles/1060967/多代 LRU (Multi-Generational LRU简称 MGLRU) 是一种替代性的 内存管理 (memory-management) 算法于 2022 年底合并入 6.1 内核 (kernel)。它曾承诺带来大幅的性能提升和更简洁的代码。然而自那时起MGLRU 的进展便陷入停滞且在许多系统中仍未启用。随着 2026 年 Linux 存储、文件系统、内存管理与 BPF 峰会 (LSFMMBPF) 的临近多位内存管理开发者表示希望讨论 MGLRU 的未来。虽然一些开发者正在寻找改进该子系统的方法但另一位开发者则呼吁将其彻底移除。MGLRU 温故知新内核必须处理的核心内存管理任务之一是确定哪些页面应保留在内存中哪些页面应被换出到较慢的存储设备中即“回收 (reclaim)”。通常最佳策略是保留近期最可能被使用的页面同时回收那些不再被使用的页面。鉴于预测未来充满挑战内核必须高度依赖有关页面近期使用情况的信息作为后续操作的指南。 最近最少使用 (Least-recently-used简称 LRU) 列表便是该解决方案的关键组成部分。内核中经典且目前仍是默认的解决方案依赖于两类 LRU 列表更准确地说是多对类似的列表分别被称为“活跃 (active)”和“非活跃 (inactive)”列表。被认为当前正在使用的页面应保留在活跃列表中而那些看似未被使用的页面则进入非活跃列表。当需要回收页面以供他用时系统会查阅非活跃列表以寻找潜在的牺牲品。该方案的大部分复杂性以及许多启发式算法都集中在如何正确设置这两个列表的大小并决定何时将页面从一个列表移动到另一个列表。MGLRU 将这种方法扩展到了多个列表称之为“代 (generations)”。在列表的一端最年轻的一代包含已知或至少被认为在不久前被使用过的页面。每一代较老的列表则追踪那些比前几代空闲时间更长的页面。各种类型的访问会将页面从较老的代移动到较年轻的代当需要更多空闲内存时内核会从最老的一代开始搜刮。据称MGLRU 能更准确地识别真正的冷页面并在执行该工作时消耗更少的 CPU 时间。关于 MGLRU 设计的更多信息请参阅 这篇 2021 年的文章。MGLRU 的困扰近期的讨论表明MGLRU 并未完全兑现其所有承诺。这一切始于 2 月中旬当时 Zicheng Wang 发起了 一项关于 LSFMMBPF 讨论 MGLRU 的请求特别是关于它在 Android 上的表现。Wang 表示尽管 MGLRU 已进入内核多年但许多 Android 系统供应商并未启用它。有多个问题影响了这一决定。其中一个抱怨后来也得到了其他人的响应是 MGLRU 无法正确平衡 匿名页 (anonymous pages) 和 文件后端页 (file-backed pages) 之间的回收。传统的 LRU 为每种页面类型维护单独的一对列表因此有了前文关于“多对”LRU 列表的评论——此外还有其他复杂情况。这两组列表的回收通常略微偏向文件后端页因为它们通常不需要写回持久存储长期存在的swappinesssysctl 调节开关 可用于调整内核攻击每个列表的激进程度。Wang 指出在启用 MGLRU 的情况下匿名页往往停留在最年轻的两代中导致它们永远不会被回收进而导致文件后端页被过度激进地回收。调整swappiness开关并不能解决这个问题。Wang 的雇主一家名为“荣耀”的 Android OEM 厂商通过显式使用内存控制组来强制回收非前台应用的匿名页但在 主线 (mainline) 内核中尚无通用解决方案。同样 提议开设 MGLRU 专题会议 的 Kairui Song 也提到了匿名页回收的问题。Wang 还有许多其他问题待讨论。MGLRU 可能会在任何给定的控制组中回收过于激进释放超出所需数量的内存。在低端设备上尤其是在可回收页面不多的情况下它的开销太大了。此外Android 对热应用和冷应用的定义旨在优先处理用户当前正在交互的应用与 MGLRU 之间存在脱节而 MGLRU与内核其他部分一样缺乏这种区分。其中一些问题已通过供应商特定的补丁 (hacks) 得到解决例如存在 一个供应商钩子 可以豁免当前前台任务免受回收。Wang 希望讨论这些供应商修改中的哪些如果有的话应该进入主线内核。Barry Song 提出了 另一个单独的抱怨当系统执行 预读 (readahead)投机性地读取它认为用户空间可能很快请求的数据时它会将所有生成的页面放入最年轻的一代即使并不能保证这些页面一定会被使用。这可能导致实际正在使用的页面被回收而预读页面却留在内存中。相比之下传统的 LRU 会将这些页面放入非活跃列表如果没有再次被引用它们会相对较快地被回收。至少这个问题应该可以通过一个相对简单的方案来解决。Kairui Song 提出的问题清单侧重点有所不同首先是 MGLRU 使用了三个 页面标志 (page flags)。这些标志 长期处于短缺状态试图分配哪怕一个标志的补丁往往都会遭遇强烈抵制。增加 MGLRU 管理的代数的想法也意味着需要使用更多的页面标志。他提议将这些标志移至别处使系统支持多达 63 代同时释放 MGLRU 当前使用的三个页面标志。另一个问题是某些工作负载的性能倒退尽管其他工作负载表现更好。Kairui Song 认为这些问题源于 MGLRU 中管理回收的控制循环可以通过更好地追踪文件后端页的使用历史来解决。然而这样做需要三个页面标志大概就是那些通过将代数移至别处刚刚释放出来的标志。他表示MGLRU 提供的指标在许多方面与传统 LRU 不同这使得系统其他部分更难理解任何给定页面的内存管理状态。他提议改变页面状态的追踪方式以改善这种状况。Kalesh Singh 也 描述了指标方面的问题称这两种 LRU 实现之间的差异巨大这给 Android 用户空间 内存不足 (Out-of-memory简称 OOM) 守护程序等组件带来了困难。顺便提一下Kairui Song 还提到了增加一个 BPF 钩子的想法以便自定义页面代放置的决策。虽然还提到了其他问题但或许令人惊讶的是大多数参与者都忽略了另一个相关议题内核中原本就存在两种竞争的 LRU 实现。Kairui Song 确实注意到他描述的问题是“MGLRU 仍不是内核中唯一 LRU 实现的诸多原因”之一。David Rientjes 补充说讨论应涵盖“需要解决哪些问题才能让 MGLRU 走上成为默认实现的道路从而消除两种独立的实现”。这将是一项艰巨的任务某些工作负载在一种实现下的表现肯定总会优于另一种因此移除其中一种必然会导致某些工作负载性能下降。将这些倒退降低到可接受的水平尚需时日。索性移除它内核开发者事实上也是许多项目中的开发者长期存在一种担忧某个开发者增加了一堆复杂的代码然后就不再负责维护了。Matthew Wilcox 断言 这种情况正发生在 MGLRU 身上在我看来MGLRU 最大的问题是 Google 把它丢给我们后就跑了。 提交 44958000bada 声称它现在已有人维护并增加了三名维护者。在该提交之后的六个月里这三个人在mm/目录下没有任何提交这种状况简直令人汗颜。我说把它拔掉吧。MGLRU 的原始开发者 Yu Zhao正如上述提交中所注目前已“转向其他项目”。从仅限订阅者的 Zhao 的 KSDB 页面 可以看到他偶尔会改进 MGLRU但最后一次是 6.14 内核中的几个提交。虽然据说有其他开发者在处理这些代码但自那以后被添加到MAINTAINERS文件中的人都没有对 MGLRU 进行过任何更改。因此在某种程度上MGLRU 被贡献给内核后不久便遭遗弃是事实。作为 MGLRU 指定维护者之一的 Axel Rasmussen 似乎同意 这一评估但他表示情况很快就会改变我承认这是一个大问题。我们在这方面辜负了社区我们计划从 4 月份开始纠正这一局面例如通过与 Kairui 及其他人合作来解决悬而未决的问题。缺乏开发者持续的关注无疑让 MGLRU 难以克服许多潜在用户遇到的问题。即便如此移除它的想法几乎没有得到支持。Barry Song 请求保留它以便解决这些问题它只需要更多的工作。MGLRU 在设计上有许多亮点包括使用更多的“代”来区分冷热页面、通过利用缓存局部性来减少扫描开销的环顾机制以及最小化锁持有的数据结构设计。Gregory Price 列举了 MGLRU 的一系列已知问题。不过他也并未要求将其彻底移出内核。因此5 月份 LSFMMBPF 上的 MGLRU 讨论似乎不太可能把时间花在彻底移除它的想法上。但人们将非常有兴趣了解需要做哪些工作才能将 MGLRU 提升到所需的性能水平并或许在某一天成为内核中唯一的 LRU 实现。如果一些开发者愿意承诺承担这些工作MGLRU 最终可能会取得过去几年一直缺失的进展。这看起来将是一场有趣的会议。LWN 评论概述评论区反映了用户对 MGLRU 的复杂态度。一方面有用户表示在内存极度超售的服务器上启用 MGLRU 后系统响应更具预测性显著改善了 SSH 登录和服务的稳定性另一方面讨论也集中在技术细节上如与 ZFS ARC 的对比以及经典 LRU 如何通过影子列表 (shadow tracking) 为交换后端页面提供工作集保护。同时也有观点认为 MGLRU 在未解决特定工作负载下的回收平衡和调优问题前尚不具备全面替代传统双列表机制的条件。全文完LWN 文章遵循 CC BY-SA 4.0 许可协议。欢迎分享、转载及基于现有协议再创作长按下面二维码关注关注 LWN 深度文章以及开源社区的各种新近言论