LWN：用 BPF 控制内存管理

作者： Jonathan Corbet
2026 年 5 月 15 日 

LSFMM+BPF 

Roman Gushchin 在 2026 年 Linux 存储、文件系统、内存管理与 BPF 峰会（LSFMM+BPF）的内存管理分会场开始了他的演讲。他提到，社区已经看到了许多为内存管理添加基于 BPF 的接口的提案。然而，目前还没有一个提案进入主线（mainline）。他希望探讨 BPF 可能发挥作用的方式，以及到目前为止阻碍基于 BPF 的解决方案进入主线的障碍。随后，Shakeel Butt 主持了一场讨论，探讨了用于内存控制组（memory control groups）的新型 BPF 接口可能需要满足哪些要求。 

BPF 集成的障碍

他首先指出，现有的尝试已经试图涵盖许多不同的内存管理启发式方法。已经有提案建议使用 BPF 来控制 内存不足处理（out-of-memory handling，OOM）、 NUMA 平衡、 内存控制组、 页面缓存置换（page-cache eviction）等。还有更多有趣的构想尚未付诸实践，包括预读（readahead）控制、 madvise() 、 内核同页合并（kernel samepage merging）以及客户机内存控制。尤其是预读，它包含了一套混乱的启发式规则，但对于性能至关重要。 

他说，为内存管理子系统添加 BPF 接口存在许多障碍；他将按照重要性从小到大的顺序进行介绍。第一个障碍是对树外（out-of-tree）BPF 程序的担忧。内核开发者希望看到生产级别的代码进入主线，但目前 BPF 的运作方式并非如此。例如，已经有了生产级别的 sched_ext 调度器，但它们都固执地留在树外。BPF 维护者 Alexei Starovoitov 表示，“ sched_ext 是一个错误”，因为它没有随之将任何生产级别的调度器带入主线。他说，这种局面现在很难扭转。如果能有一个好的树内 OOM 处理器就好了；即便没有别的作用，它也能帮助开发者评估提议的接口。 

Gushchin 说，在内核树中包含 BPF 程序似乎并无争议，因此真正的问题在于开发者应该走多远。第一步可以仅仅是包含源码供人们研究和试用。Starovoitov 说，自动加载内置的 BPF 程序可能是很好的第二步；这能让人们轻松地使用内置的 BPF 程序。Gushchin 建议，一个基于 BPF 实现的 systemd-oomd 将是展示该子系统如何运作的一个绝佳范例。 

另一个障碍是目前无法将 struct ops 程序挂载到控制组（cgroup）上。虽然可以挂载普通的 BPF 程序 ，但无法挂载那些使用 struct ops 接口的程序。他已经为 OOM 处理器提供了一个实现，但 sched_ext 使用的是另一种解决方案。 

接下来是安全性和回退（fallback）问题；一个有缺陷的 BPF 内存管理程序可能会轻而易举地使系统无法使用。在 Gushchin 看来，这是最难解决的问题；甚至很难定义在这种情况下“安全性”意味着什么。他说，基于时间的回退方案难以实现且不够优雅。内存管理操作可以被封装进受监控的 kfuncs 中，但这会导致非通用的解决方案，从而损害性能。需要定义可接受的服务级别；一个丢弃所有数据包的流量控制程序是可以接受的，但一个让系统中一半任务处于饥饿状态的 sched_ext 调度器则没那么容易被接受。如果加载了一个有问题的 BPF 程序，导致系统再也无法回收内存，该怎么办？ 

对于热路径（hot path）性能的担忧将一直存在，这使得在最核心的路径中添加 BPF 程序变得难以自圆其说。内存管理子系统在很大程度上依赖批处理（batching）来提升性能，这就产生了一个问题：BPF 程序应该在批处理之前还是之后运行？他建议批处理应该先行，但这使得无法通过 BPF 程序来控制批处理本身。 

最后，他说最重要的障碍是 ABI 的稳定性；这一担忧最近刚被 David Hildenbrand 在邮件列表中 提出。Hildenbrand 在现场表示，关于为 BPF 程序提供钩子（hook）意味着什么，存在一些困惑：它们是一种永久性的内存管理特性吗？社区可能并不想承诺无限期地保留这些钩子。这种担忧导致了一项决定，即不为透明大页（transparent huge pages）的管理提供钩子；他说，没人知道五年后情况会变成什么样，因此现在不可能设计出正确的接口。 

他说，未来可能会发生这样的情况：内存管理开发者某天醒来，意识到接口的某些方面应该换一种做法。如果他们付诸行动，程序就会崩溃，人们会感到愤怒。或许解决方案是仅承诺支持那些在内核树本身维护的 BPF 程序。Hildenbrand 最后总结道，他看到了使用 BPF 的价值，但担心添加接口可能会迫使子系统在未来去维护那些令其后悔的特性。 

演讲此时已到预定时间。在结束语中，Gushchin 表示，仅添加最通用的 BPF 钩子至关重要。例如，添加一个用于分配 OOM 分数的钩子可能不是个好主意，因为未来的 OOM 杀手可能不再使用这些分数。但一个在压力下释放内存（或许是通过杀掉某些进程）的钩子可能会很有用。 

重新构想内存控制组

紧接着，Shakeel Butt 讨论了他希望看到的内核 内存控制器（memory controller）的演进方向，以及 BPF 如何融入其中。他首先介绍说，内存控制器分层级地分配内存资源，并实现了硬限制（hard limit）和软限制（soft limit）。当内存充裕时，任何给定的组都可以使用多达其硬限制的内存，但当内存紧张时，其用量会被压缩回软限制。 

他说，内存控制器面临着许多挑战。限制的执行缺乏灵活性且具有干扰性；由于它是同步发生的，可能会导致对延迟敏感的线程出现意外停顿。其接口已被证明难以演进，因为重大更改会破坏现有的 ABI，而内核开发者是不允许这么做的。他说，如果有一种机制能让实验替代方案成为可能，那就太好了。 

新接口的目标是提供能够支持各种用例的能力。 他的会议提案中提供了一个用例示例，并在会议期间再次提及： 

策略：“将系统级内存利用率保持在 95% 以下；通过不限制持有锁的分配器来避免优先级反转（priority inversions）；在不降低相关性能指标的前提下，将每个工作负载的用量削减至其工作集（working set）大小；与工作负载协作进行减载和内存削减决策；在极端内存压力下，与 OOM 杀手和中央作业调度器协作，杀死并清理某个工作负载。” 

他说，新的内存控制器需要提供应用程序可以响应的内存使用通知。它需要支持后台回收（background reclaim），以便在不阻塞运行线程的情况下执行内存限制。内存使用限制（throttling）应该能感知到持有锁的线程，以避免优先级反转问题。用户空间需要能够以其他方式影响限制操作，例如，能够识别出哪些特定线程在一定程度上应该被豁免。控制器还应支持内存分层（memory tiering），提供对页面在各层之间迁移方式的控制。 

由于时间紧迫，无法深入探讨这一新接口的具体运作方式；总的来说，这项工作似乎还处于早期阶段。Butt 说，可以添加一个新的 BPF 回调函数 bpf_memcg_charge_succeed() ，以告知 BPF 程序内存用量的增加；该程序随后可能会通过启动后台回收来做出响应。其他回调函数可以在控制组达到使用水位线（或触及使用上限）时通知程序，并依靠程序提供如何应对的暗示。该程序可能会启动某种形式的回收，但它也可以将情况告知应用程序，并期望该应用程序通过减少其内存用量来做出响应。 

最后，一名听众提到，一个有用的特性是能够内省应用程序正在使用哪些类型的内存；Butt 回答说，这项特性已经在开发中了。 

LWN 评论概述：

[一位未知用户对 BPF 在内存管理中的稳定性发表了看法…] 

审视支持 BPF 稳定性的问题非常有趣。从技术上讲，文档确实做出了一些关于 ABI 的声明，例如 kfuncs 可能随时发生变化，而 BPF 辅助函数（helpers）则不然，且被认为是稳定的。 

要论证在 BPF 中验证内存管理程序的可行性是件难事。似乎不太可能在第一次尝试时就获得一个足够灵活、能涵盖所有用例，同时又不从根本上破坏验证器（verifier）所提供的“安全性”的方案。所以我明白为什么这成了一个棘手的话题。 

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