When OOM Killing Becomes a Policy Debate: The ‘oom_pardon’ Patch and Its Critics

---

The proposal that raised eyebrows

In September 2004, Thomas Habets submitted a patch named oom_pardon to the Linux kernel mailing list. The idea was simple: add a sysctl flag that, when enabled, would prevent the OOM killer from terminating a predefined set of processes (most notably the X server’s lock daemon). If the system ran out of memory and no other process could be killed, the kernel would panic instead of taking down the user’s graphical session.

Habets framed the request with a tongue‑in‑cheek analogy about an airline that, to save fuel, would eject passengers when the plane ran low on fuel. The analogy was meant to illustrate the absurdity of killing a user‑visible service that people rely on for basic interaction with their machine.

---

Community reaction: support, skepticism, and a call for nuance

A pragmatic minority

A handful of developers, especially those working on desktop‑oriented distributions, responded positively. Their argument rested on three observations:

1. User experience matters. When the OOM killer terminates the X lock daemon, the screen freezes and users are forced to reboot, losing unsaved work. A panic, while still disruptive, can be caught by a watchdog and result in a cleaner shutdown.
2. Selective protection is feasible. The kernel already supports oom_score_adj and oom_score tweaks per‑process. Adding a whitelist‑style sysctl seemed a natural extension.
3. Existing workarounds are messy. Some distributions already ship custom scripts that monitor memory pressure and restart the X server pre‑emptively, a hack that the patch could replace.

These contributors pointed to the already‑existing oom_killer heuristics and suggested that a whitelist could be implemented without breaking the core algorithm.

The majority: caution and principle‑based objections

The bulk of the response, however, was skeptical. The concerns fell into three categories:

1. Undermining the OOM killer’s purpose. The OOM killer exists to keep the system alive when memory is exhausted. By refusing to kill a specific process, the kernel might be forced into a panic loop, potentially corrupting filesystems or losing data.
2. Policy creep. If a whitelist for X lock daemons is acceptable, where does it stop? Developers began listing other “essential” services—network managers, init systems, even user‑space daemons—creating a slippery slope that could render the OOM killer ineffective.
3. Implementation complexity. Adding a global sysctl that overrides the per‑process oom_score_adj could introduce race conditions. The OOM killer runs in an interrupt context; any additional checks must be lock‑free and fast, otherwise the kernel could deadlock during a memory crisis.

One responder, Andries Brouwer, used the same airline metaphor to highlight the absurdity of “ejecting” a passenger (process) only when the plane (system) is already in trouble. He warned that a mechanism that sometimes ejects passengers even when there is no fuel shortage would be a bug, not a feature.

A middle ground: configurable thresholds

A recurring suggestion was to expose per‑process OOM scores rather than a blanket exemption. By allowing administrators to set a high oom_score_adj (e.g., -1000) for the X lock daemon, the kernel would still consider it for killing but only as a last resort. This approach keeps the OOM killer’s decision‑making intact while giving power users a way to protect critical services.

Another idea was to tie the exemption to cgroup memory limits. If a cgroup containing the X server hits its memory quota, the OOM killer could be instructed to kill processes outside that cgroup first, preserving the user’s desktop session.

---

What the discussion reveals about community sentiment

• Desktop vs. server priorities. The patch sparked a classic divide: desktop users value a responsive UI even at the cost of a hard reboot, while server operators prioritize system stability above all.
• Policy vs. mechanism. The kernel community prefers mechanisms that are predictable and transparent. Adding a “don’t kill me” flag was seen as a policy decision that belongs in distribution‑level tooling, not in the kernel core.
• Risk aversion. Even well‑intentioned patches are scrutinized for potential side effects under extreme conditions. The kernel’s reputation for reliability makes developers wary of any change that could exacerbate a crash.

---

Counter‑arguments that kept the debate alive

1. Real‑world incidents. Some developers cited cases where the OOM killer terminated the X server during a memory leak, leaving users unable to log in and forcing a hard reset. They argued that a panic could be caught by a kexec‑based fallback, resulting in a faster recovery.
2. User‑space solutions are brittle. Scripts that monitor /proc/meminfo and restart services can miss the narrow window when the kernel is already deadlocked, whereas a kernel‑level exemption would act instantly.
3. Historical precedent. The kernel already contains oom_kill_disable for critical kernel threads. Extending a similar concept to user‑space processes was not unprecedented, and the code path was already audited for safety.

---

Where the conversation headed

The patch never landed in the mainline kernel. Instead, the discussion influenced later developments:

• The cgroup v2 memory controller now offers fine‑grained OOM handling, allowing administrators to define memory.low and memory.high thresholds that affect kill order.
• Tools like systemd-oomd provide user‑space OOM monitoring and can be configured to protect specific services without touching the kernel.
• The kernel’s oom_score_adj interface remains the recommended way to influence kill priority, with documentation emphasizing that values should be used sparingly.

In hindsight, the oom_pardon debate highlighted a recurring theme in kernel development: policy belongs higher up the stack. While the kernel can expose knobs, the responsibility for deciding which processes are “essential” rests with the distribution or the system administrator.

---

The original mailing list thread can be found in the Linux Kernel Archive archives, and the patch itself is still available on the LKML mailing list archive.