引言：8000行代码的"泥潭"
在 Linux 内核的内存管理（MM）领域，mm/vmscan.c 一直是核心中的核心。然而，最近的一场社区大讨论打破了平静。随着 MGLRU（多代最近最少使用算法）在 6.1 版本合并，内核现在实际上运行着两套完全平行的页面回收路径。
这种"双轨制"导致 vmscan.c 迅速膨胀至 8000 多行，且其中 40% 是重复逻辑。面对日益沉重的维护负担，Google、Oracle、SUSE 等大厂的顶尖开发者们正试图推动一场变革------Towards Unified and Extensible Memory Reclaim (reclaim_ext)。
一、 核心矛盾：高性能"黑盒" vs. 稳健"老兵"
在最近的邮件往来中，几位技术巨头的观点针锋相对：
-
MGLRU (新锐派)： 在 Android 和 ChromeOS 上表现惊人，解决了内存抖动（Thrashing）问题，但在内核专家眼中，它像个"黑盒"，内部逻辑（如代号更新与原子锁）高度耦合，极难维护。
-
传统 LRU (保守派)： 虽然架构陈旧（双级队列），但经过数十年的战场检验，支持着无数复杂的企业级服务器场景。
二、 破局方案：reclaim_ext 与 reclaim_ops
为了解决代码冗余，Shakeel Butt 提出了 reclaim_ext 构想，其核心理念是**"机制与策略分离"**。
1. 提取公共"机制 (Mechanisms)"
开发者们达成共识：不应该让 MGLRU 独占好主意。
-
前向页表扫描 (Page Table Walking)：MGLRU 引入的高效扫描机制应被提取为通用 Helper 函数，让传统 LRU 也能共享。
-
布隆过滤器 (Bloom Filters)：用于快速过滤活跃页面的技术，也应进入"公共工具箱"。
2. 定义策略接口 (reclaim_ops)
通过定义一套标准的函数指针接口（类似文件系统的 VFS 层），让内核核心只负责执行"搬运"和"释放"动作，而将"决定回收谁"的逻辑交给不同的插件。
三、 深度辩论：我们需要"万灵药"还是"手术刀"？
这场讨论中最精彩的部分在于对可扩展性的思考：
-
"没有普适算法"论 ：来自哥伦比亚大学的 Tal Zussman 提交了实测数据。他发现，在 HTAP 数据库等混合负载下，通用的 MGLRU 依然会被大规模扫描污染。而通过 eBPF (reclaim_ext) 自定义一套简单的 MRU（最近最常使用）策略，吞吐量竟然提升了 70%！
-
eBPF 的介入：Gregory Price 提出了一个激进的想法------既然通用的启发式算法总有盲点，为什么不直接把回收决策交给 eBPF？让数据库自己告诉内核："现在我在做全表扫描，请优先回收这些临时页"。
四、 现状与未来：文化转型的开始
除了技术，这次讨论更揭示了 Linux 社区文化的转型：
-
清算"挂名"维护者 ：Lorenzo Stoakes 尖锐地指出，目前的
MAINTAINERS名单中有人已长期不活跃，导致 MGLRU 处于"无人驾驶"状态。社区正准备更新名单，让真正贡献代码的人拥有话语权。 -
拒绝"全盘接收"：开发者们反思了 MGLRU 当初以"黑盒"形式合并的教训。未来的新特性必须满足**"可解耦、可验证、低冗余"**的硬性指标。
结语
Linux 内存回收的这场重构不仅是为了减少几千行代码，更是为了构建一个更灵活、透明的底层架构。对于开发者而言，这释放了一个信号：内核正变得越来越模块化，eBPF 等现代工具正在深度渗透进最核心的资源调度逻辑。
