Why oom_reaper when having vm.panic_on_oom = 1

Question

From what I understand from its author :

The OOM killer currently allows to kill only a single task in a good hope that the task will terminate in a reasonable time and frees up its memory. (…)

It has been shown (e.g. by Tetsuo Handa) that it is not that hard to construct workloads which break the core assumption mentioned above and the OOM victim might take unbounded amount of time to exit because it might be blocked in the uninterruptible state waiting for on an event (e.g. lock) which is blocked by another task looping in the page allocator.

This patch reduces the probability of such a lockup by introducing a specialized kernel thread (oom_reaper) which tries to reclaim additional memory by preemptively reaping the anonymous or swapped out memory owned by the oom victim under an assumption that such a memory won't be needed when its owner is killed and kicked from the userspace anyway.

In short, the oom_reaper kernel thread aims at lowering the probability of inappropriate decisions from the oom_killer.

From what I understand from RHEL 8 documentation :

The /proc/sys/vm/panic_on_oom file contains a value which is the switch that controls Out of Memory (OOM) behavior. When the file contains 1, the kernel panics on OOM and stops functioning as expected.

The default value is 0, which instructs the kernel to call the oom_killer function when the system is in an OOM state.

In short : having vm.panic_on_oom = 1 an OOM state won't trigger oom_killer launch.

And therefore, logically, no need for its oom_reaper crutch.

However, oom_reaper appears launched (under linux-5.4) at system init irrespective of vm.panic_on_oom value.

Why ? Is there something I missed ? Something that makes the oom_reaper necessary even in case the killer won't ever be launched ? If not, how is it possible to prevent oom_reaper to be launched when vm.panic_on_oom = 1 ?

---

Note 1 : Of course I understand from the reading of the code that it won't be built if CONFIG_MMU is not set but this is obviously not an option on my system.

Answer 1

There's multiple things that are called "OOM killer" etc. You disabled the kernel-integrated last-resort OOM killer functionality. That has nothing to do with any daemons being launched.

Multiple system utilities have implemented smarter ways of killing memory-exploding processes before they render your system inoperable over the years. Chances are you're dealing with the systemd OOM killer (which definitely has saved the author's behind a number of times).

See man oomd.conf for how to configure systemd-oomd. In the extreme case you actually want to disable it (why? you just render your system unrecoverable!), you can disable it like any other service using systemctl disable xyz.service.

(Oh, and there's also some malware targeting COTS NAS boxes that has a process name of oom_reaper as well, but that's probably not what you're dealing with.)

Answer 2

As for why :

Because whatever userland process is capable of ooming the system, the default framework for managing oom situations (oom-killer + oom-reaper) needs to be in place before the first userland program can run.
That is to say before the startup procedure organized by sysV init or systemd.
That is also to say before the system being aware of sysctl values since these are set by the sysctl service launched at startup time.

Moreover, this setting is subject to changes at runtime via sysctl or even /proc/sys/vm/panic_on_oom.

All this leaving the vm.panic_on_oom setting unpredictable at boot time.

As for how to get rid of that :

If the code suggests that it would not be built if CONFIG_MMU = n, this is (fortunately) not an option for my arch. Then the most immediate way to prevent oom_reaper from being launched would be to simply comment the subsys_initcall(oom_init) line. But I am still unsure regarding the side effects.