引言

作为 Linux 内核中一项革命性的技术，eBPF（Extended Berkeley Packet Filter，扩展版伯克利包过滤器） 正在以前所未有的速度改变着操作系统的底层生态。它允许开发者在不修改内核源码、不需要重启内核的前提下，安全地在内核中运行自定义程序。这种“即插即用”、兼顾极致性能与绝对安全的特性，已经让 eBPF 在网络（如 Cilium）、可观测性（如 BCC、Pixie）以及安全审计（如 Falco）三大领域大放异彩。

然而，当这把“瑞士军刀”试图挥向 Linux 内核最核心、最复杂的堡垒之一——内存管理（Memory Management）子系统时，却遭遇了前所未有的博弈与思辨。

在 2026 年 Linux 存储、文件系统、内存管理和 BPF 峰会（LSFMM+BPF Summit）上，核心开发者 Roman Gushchin 和 Shakeel Butt 的两场连续议题，为我们清晰地勾勒出了 eBPF 在内存管理领域的应用前景、当前面临的重重阻碍，以及如何利用 eBPF 重新构想下一代内存控制组（cgroup memory controller）。

第一部分：eBPF 的核心本质与核心原理

要理解 eBPF 为何能在内存管理中有所作为，首先需要理解它的底层工作机制。

1. 为什么需要 eBPF？

在传统 Linux 开发中，修改内存管理策略（如改变页面淘汰算法、优化 OOM 行为）只有两条路：要么修改内核源码（周期漫长，动辄数年才能进入主线发行版），要么编写内核模块（极易导致系统崩溃/蓝屏）。eBPF 完美解决了这一痛点。

2. eBPF 的工作流程

eBPF 程序通常遵循“事件驱动”模型，其核心流程如下：

• 编写与编译：使用 C 或 Rust 编写 eBPF 代码，通过 LLVM/Clang 编译成 eBPF 字节码。

• 加载与验证（Verifier）：用户态程序将字节码加载到内核。内核中的验证器进行严格审查，确保代码不会崩溃、不会死循环、不会非法访问内存。

• JIT 即时编译：通过验证后，JIT 编译器将字节码翻译成当前 CPU 的原生机器码，执行速度与原生内核代码无异。

• 事件触发：将程序附加（Attach）到内核的特定“钩子（Hook）”上，当特定事件（如系统调用、内存分配、OOM 触发）发生时，程序自动执行。

第二部分：eBPF 进军内存管理：探索与阻碍

在 2026 年的峰会上，Roman Gushchin 首先开启了关于 BPF 集成的讨论。他指出，尽管社区涌现出大量为内存管理添加基于 BPF 接口的提案，但目前没有任何一个成功进入主线内核。

1. eBPF 在内存管理中的潜在应用场景

现有的探索尝试捕获各种不同的内存管理启发式算法（heuristics）：

• 已有的提案：使用 eBPF 来控制内存不足（OOM）处理、NUMA 平衡、内存控制组（memcg）、页缓存淘汰（page-cache eviction）等。

• 尚未付诸实践的想法：预读控制（readahead control，一套繁杂但对性能至关重要的启发式算法）、madvise()、内核同页合并（KSM）以及客户机内存控制（guest-memory control）。

2. 阻碍 BPF 集成的六大内核壁垒

Gushchin 按照重要性由低到高的顺序，梳理了阻碍 eBPF 融入内存管理系统的六大障碍：

• 树外（out-of-tree）程序的隐忧：内核开发者希望生产级别的代码进入主线。但目前许多优秀的 BPF 程序（如 sched_ext 调度器）都固执地留在内核树外。BPF 维护者 Alexei Starovoitov 甚至直言“sched_ext 是个错误”，因为它未能将生产级调度器带入主线。因此，内存管理领域急需一个优秀的、树内的 OOM 处理器作为示范。

• 源码包含的边界问题：在内核树中包含 BPF 程序源码并无争议，但究竟该走到哪一步？第一步是包含源码供试用，第二步（Starovoitov 建议）是自动加载内置 BPF 程序。Gushchin 提出，实现一个 BPF 版本的 systemd-oomd 将是极佳的示例。

• 架构特性的限制：目前无法将 struct ops 类型的 BPF 程序附加到控制组（cgroup），这限制了内存控制接口的灵活性。

• 安全性与回退（fallback）机制的缺失：这是最难解决的问题。一个出现故障的 BPF 内存管理程序极易导致系统不可用。如果加载了有缺陷的 BPF 程序，导致系统再也无法回收内存，该怎么办？基于时间的回退机制难以优雅实现，将操作封装到 kfuncs 又会损害通用性和性能。

• 热路径（hot paths）的性能担忧：内存管理极度依赖“批量处理（batching）”来提升性能。BPF 程序如果放在批量处理前，就无法控制批量处理本身；如果放在后面，又会破坏热路径的极致性能。

• ABI 的稳定性（最核心阻碍）：内核核心开发者 David Hildenbrand 强调，为 BPF 提供钩子是否意味着社区要无限期地保留它们？在内存管理领域（如透明大页 THP），没人能预测五年后的架构格局。如果未来为了优化而修改了接口，树外的 BPF 程序就会崩塌，引发用户愤怒。希尔登布兰德担心，引入这些接口可能会迫使子系统在未来不得不去维护一些令其后悔的特性。

破局共识：在会议结束时，Gushchin 提出务必只添加最通用的 BPF 钩子。例如，添加分配 OOM 分数的钩子是个坏主意（因为未来的 OOM 机制可能会抛弃分数制）；而添加一个“在内存压力下通过杀死某些进程来释放内存”的通用钩子，则非常有价值。

第三部分：重新构想：基于 eBPF 的内存控制组

紧随 Gushchin 的讨论，Shakeel Butt 带来了更具体的应用蓝图：如何利用 eBPF 重新引导内核内存控制器（memory controller）的演进。

1. 传统内存控制器的痛点

目前的 cgroup 内存控制器通过层级结构分配资源，实施硬限制（hard limits）和软限制（soft limits）。但它面临两大挑战：

1. 执行缺乏弹性且具破坏性：限制的执行同步发生，会导致延迟敏感的线程出现意料之外的卡顿。

2. 接口难以演进：重大改动会破坏现有 ABI，这是内核“不可触碰的红线”。因此，急需一种机制来允许开发者安全地实验替代方案。

2. 完美的内存管理策略（Policy）蓝图

基于 eBPF 的新接口，其目标是支持极具弹性和上下文感知的复杂业务策略。例如：

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

3. eBPF 如何在其中发挥作用？

虽然该项目处于早期阶段，但 Butt 提出了几个关键的 eBPF 回调函数（Callbacks）构想，展现了 eBPF 在内存控制中的具体应用方式：

BPF 回调函数 / 机制	触发时机	预期响应行为
bpf_memcg_charge_succeed()	内存用量增加、成功计费时	通知 BPF 程序，在后台异步启动后台回收（background reclaim），避免卡顿当前运行线程。
水位线/限制回调	控制组达到使用水位线（watermark）或触发限制时	BPF 程序向内核提供如何应对的提示，或者将情况异步通知给用户态应用程序，让应用主动减少内存占用。
锁感知与线程豁免	内存限流（throttling）发生时	BPF 程序识别特定线程（如持有关键锁的线程），对其进行限流豁免，防止系统级优先级反转。
内存分层控制（Tiering）	内存跨介质迁移时	允许 BPF 程序灵活控制页面在不同层级（如高速缓存、普通内存、持久内存）之间的迁移时机与策略。

此外，针对听众提出的“自省（introspect）应用程序正在使用哪些类型的内存”这一需求，Butt 透露该功能也已经在使用 eBPF 的框架下进行开发。

结语：eBPF 在内存管理领域的未来

从核心技术特性来看，eBPF 的高性能、安全性和非侵入性，使其成为破解 Linux 内存管理“ABI 固化、策略死板、热路径卡顿”等顽疾的完美解药。通过将复杂的策略（如锁感知限流、异步后台回收）剥离到可动态加载的 eBPF 程序中，内核得以保持核心的纯粹与通用。

然而，内存管理子系统作为操作系统的地基，对 ABI 稳定性、热路径性能以及系统级安全性的要求近乎苛刻。Hildenbrand 等内核权威专家的担忧并非没有道理——一旦接口放开，维护成本可能会变成巨大的历史包袱。

展望未来，eBPF 在内存管理领域的应用不会是一场激进的颠覆，而将是一场有克制的改良。正如峰会达成的共识，社区将倾向于“仅在内核树内维护 BPF 程序”，并“只提供最通用、最抽象的内核钩子”。通过这种守正创新的方式，eBPF 将在保障 Linux 内核绝对稳定的前提下，为下一代高效、智能、具备业务感知能力的内存管理系统注入灵魂。