LWN：使用BPF来选择OOM kill的对象！

关注了就能看到更多这么棒的文章哦～

Out-of-memory victim selection with BPF

By Jonathan Corbet
August 17, 2023
ChatGPT assisted translation
https://lwn.net/Articles/941614/

默认配置下的 Linux 内核允许进程分配的内存比系统实际可提供的内存更多。这个策略可以更好地利用物理内存，通常情况下也都能达到目的。然而，在某些情况下，内核可能会发现无法提供出来进程认为本已经属于它们的内存。在情况严重时，除了重新启动之外，唯一的解决方法就是宣布内存不够，从而通过终止若干进程来补上这些内存空间。多年来人们付出了很大的努力来制定一些启发式方法，从而挑选出用户可能最不需要的进程。然而很明显，这个解决方案并没有让所有人都满意，因此在不久之前，有人引入了新的方法，使用 BPF 来选择 out-of-memory（OOM）时应该终结的进程。

当内存用尽时，寻找要牺牲的进程有许多方法。比如使用了最多内存的进程就是一个显而易见的选择，但该进程通常是系统中比较重要的组件，例如窗口系统服务器，或数据库管理器（database manager）。因此，多年来，开发人员自然开始试着让内核能够做出更好的选择。可以查看 LWN 内核相关文章的索引，就能看到随着时间的推移，情况发生了那些变化。在当前的内核中，这个决策的核心是一个名为 oom_badness()的函数，该函数会先跳过那些因某种原因而无法终止的进程，然后来进行一些简单的计算。一个进程的“OOM score”值取决于它使用的内存数量，并且经过该进程的 oom_score_adj 值来进行调整。通过调整这些参数，用户空间就可以保护某些进程不被 OOM-killer 杀死，而是让它去杀掉其他一些更应该被 kill 的进程。

然而，对于某些用户来说，这种控制方式显然不够。Chuyi Zhou 的 BPF 补丁系列就是最新的一种希望改进这种控制方式的方案。

在当前的内核中，OOM killer 将遍历所有可能的目标进程，在每个进程上调用 oom_badness()，然后选择分数最高的进程作为目标。Zhou 的 patch set 可以把 oom_badness()检查替换为调用一个 BPF 函数，该函数应该被定义为“fmod_ret” tracing 函数（这意味着它在从内核内部函数返回时被调用，并且可以更改该函数的返回值），它具有以下名称和原型：

int bpf_oom_evaluate_task(struct task_struct *task, struct oom_control *oc);

该函数将在评估每个可能被 kill 对象的一开始时被调用，并且如果它对指定任务做出了决策，就会让正常的评估过程被跳过。oom_control 结构描述了 OOM kill 所发生的上下文；BPF 函数可以访问这个结构，但可能（实际文档上并没有明确写出这个规则）不应对其进行更改。该函数还可以查看正在考虑要 kill 的 task 并最终决定其命运，通过返回值来反映出来：

• NO_BPF_POLICY：没有对应的策略，也就是应该使用正常的 oom_badness()方法。
  

• BPF_EVAL_ABORT：退出这个选择过程，任何一个进程都不 kill。
  

• BPF_EVAL_NEXT：跳过当前进程，看下一个。
  

• BPF_EVAL_SELECT：选择当前进程为要 kill 的进程。
  

在返回 BPF_EVAL_SELECT 时，并不意味着就结束了遍历进程列表的过程；如果还有更多需要检查的进程，就会进一步调用 bpf_oom_evaluate_task()。因此，该函数可以改变主意，也就是说如果在后面出现了更应该 kill 的进程的话，就可以再次返回 BPF_EVAL_SELECT。

可以在某些进程中使用 BPF_EVAL_NEXT，同时在其他进程中使用 NO_BPF_POLICY。最终结果将可以保护一些进程免受 OOM（内存不足）killer 的影响，同时让内核按照通常的方式来选择其余进程。然而，混合使用 BPF_EVAL_SELECT 和 NO_BPF_POLICY 看起来可能会产生意想不到的结果，这种组合似乎不是作者期望大家使用的方式，应该尽量避免，除非在将来的版本中有相关更改。

具体而言，oom_control 结构包含了一个名为 chosen 的指针，用于标识当前选中的受害者，以及一个名为 chosen_points 的整数，用于保存其 badness 分数。在没有 BPF 程序的情况下，内核会拿每个进程的分数跟 chosen_points 进行比较，并在新进程的分数较高时来同时更新。如果返回 BPF_EVAL_SELECT，则会设置 chosen 而不设置 chosen_points。如果对于后续有个进程返回了 BPF_NO_POLICY，那么其分数将与一个跟之前选择的进程无关的 chosen_points 进行比较。

此外，这组 patch 还提供了两个相关的 hook。其中一个允许将当前选择受害者的策略的名称存储在内核中；这个名字会在实际执行 kill 时记录到日志中。为了实现这个功能，程序应该定义一个名为 bpf_set_policy_name 的函数：

void bpf_set_policy_name(struct oom_control *oc);

这个函数将在 OOM-kill 过程的一开始时就调用，然后可以调用以下函数：

void set_oom_policy_name(struct oom_control *oc, const char *name, size_t sz);

其中，oc 是传递给 bpf_set_policy_name 的 oom_control 结构，name 是要使用的策略的名字，sz 是该名称的长度。name 限制为 16 字节，包括终止 NUL 字节。

此外，还引入了一个新的 tracepoint，名为 select_bad_process_end，在 OOM-kill 过程无法找到要 kill 的进程时触发。目标是为试图开发新的 OOM-kill 策略的开发人员提供帮助。

这组 patch 目前正在第二次修订。在第一次法布施，内存管理开发者 Michal Hocko 建议简化一下接口。而 Roman Gushchin 则主张采用更通用的方式，也就是在 OOM 时调用一次 BPF 程序，期望它能找到某种方式来释放一些内存。Hocko 回应说最好从一个 "something that is good enough" 开始，后续有必要的话再增加复杂逻辑。在对第二次修订的回应中，Alexei Starovoitov 也支持使用更通用化的 callback，而 Chuyi Zhou 已经开始认真考虑做这种更改会有哪些影响。

Hocko 和 Gushchin 都表示担心将 BPF 引入这段在系统处于紧急状态时运行的代码可能会进一步降低内存不足情况下的稳定性。例如，尝试在这种情况下分配大量内存的 BPF 程序可能就会出现问题。然而，任何 hook 到 OOM-killer 的代码都有这个问题，而不是 BPF 方案特有的问题。

这次讨论显示出，使用 BPF 来选择 OOM-killer 的受害者这个方案挺有吸引力。然而，到目前为止，关于这项工作所应采取的实现方法尚无明确共识。因此，在进入 mainline 之前很可能还会看到这个功能经历一些重大变化；在那之前，内核将不得不继续以传统方式来选择要牺牲的进程。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

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

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～