这条讨论围绕一项名为 “OOM_pardon, a.k.a. don't kill my xlock” 的 Linux 内核补丁展开，核心问题是：当系统陷入内存耗尽时，OOM killer 是否应该避开像 xlock 这样的屏幕锁定进程。xlock 是 X11（老式图形系统）里的锁屏程序，如果它被杀掉，某些实现可能会导致会话直接解锁，因此争论不只是“保活”而是“安全边界是否会失败打开”。评论把问题延伸到 Linux 的 memory overcommit（超额承诺内存）和按需分页机制：即使某进程没在“申请内存”的那一刻出问题，也可能在之后的页面访问时触发 OOM。讨论中还提到 `oom_score_adj=-1000` 这类现成的 per-process 调整手段，以及 `mlockall(2)`、`madvise` 等让关键程序更不容易因缺页而死的方法。
有人吐槽到了 2026 年，Linux 的 OOM killer 依然很难优先干掉 Firefox，而不是别的进程。评论里也延伸到 Chrome 经常“跑飞”占满内存，最后只能靠手动 `killall -9 chrome` 处理。这个分支更像是对桌面浏览器内存膨胀的日常抱怨，顺带调侃 OOM 机制的选择结果并不总是符合直觉。
一部分人主张，应该让真正尝试分配内存的进程自己崩掉，而不是让无辜的关键进程被随机挑中。反对者指出，Linux 的 overcommit 和按需缺页会让 OOM 在“访问页面”时才爆发，因此触发点未必是最近申请内存的进程。若没有某种选择机制，就会变成“随机死一个”，也就是所谓的 OOM roulette。
有人认为 xlock 这类关键锁屏程序应该用静态内存、避免再次分配，并尽量通过 `mlockall(2)` 之类方法减少被换出或触发缺页的机会。也有人直接指出，xlock 崩溃后竟然会把 X11 会话解锁，这在安全上非常离谱，因为锁屏不该只是认证桌面的一个普通图层。讨论进一步上升到安全原则：如果系统安全依赖锁屏不崩，那这个系统本身就不够安全，锁屏应当 fail closed，而不是 fail open。
有人提到其实已经可以通过把进程的 `oom_score_adj` 设为 `-1000` 来避免被 OOM killer 杀掉，因此最初对这个补丁的必要性有些困惑。这个观点暗示，问题可能不在于完全没有控制手段，而在于锁屏程序是否默认正确使用了这些机制，以及补丁是不是只是把已有能力做成更明确的保护策略。也就是说，争论焦点从“能不能免死”变成了“该不该默认特赦这类进程”。
OOM killer: Linux 在内存严重不足时触发的进程回收机制，用来挑选并杀死某个进程以释放内存。
overcommit: Linux 允许先“承诺”超过物理内存的内存分配策略，真正用到页面时才可能暴露内存不足。
xlock: X11 环境下的屏幕锁定程序，负责在会话上锁后阻止未授权访问。
oom_score_adj: Linux 中用于调整进程被 OOM killer 选中概率的参数，数值越低通常越不容易被杀。
mlockall(2): 一个系统调用，可将进程内存锁定在 RAM 中，减少被换出到 swap 的可能。
MCL_ONFAULT: `mlockall` 的一个标志，表示在页面首次缺页时再锁定，常用于减少启动时的内存压力。
MADV_POPULATE_*: `madvise` 的一组提示，用于预先触发页面填充，降低运行时因缺页导致的意外失败。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。