On Mon, Aug 18, 2025 at 10:01:22AM -0700, Roman Gushchin wrote: > This patchset adds an ability to customize the out of memory > handling using bpf. > > It focuses on two parts: > 1) OOM handling policy, > 2) PSI-based OOM invocation. > > The idea to use bpf for customizing the OOM handling is not new, but > unlike the previous proposal [1], which augmented the existing task > ranking policy, this one tries to be as generic as possible and > leverage the full power of the modern bpf. > > It provides a generic interface which is called before the existing OOM > killer code and allows implementing any policy, e.g. picking a victim > task or memory cgroup or potentially even releasing memory in other > ways, e.g. deleting tmpfs files (the last one might require some > additional but relatively simple changes). The releasing memory part is really interesting and useful. I can see much more reliable and targetted oom reaping with this approach. > > The past attempt to implement memory-cgroup aware policy [2] showed > that there are multiple opinions on what the best policy is. As it's > highly workload-dependent and specific to a concrete way of organizing > workloads, the structure of the cgroup tree etc, and user space policies like Google has very clear priorities among concurrently running workloads while many other users do not. > a customizable > bpf-based implementation is preferable over a in-kernel implementation > with a dozen on sysctls. +1 > > The second part is related to the fundamental question on when to > declare the OOM event. It's a trade-off between the risk of > unnecessary OOM kills and associated work losses and the risk of > infinite trashing and effective soft lockups. In the last few years > several PSI-based userspace solutions were developed (e.g. OOMd [3] or > systemd-OOMd [4] and Android's LMKD (https://source.android.com/docs/core/perf/lmkd) uses PSI too. > ). The common idea was to use userspace daemons to > implement custom OOM logic as well as rely on PSI monitoring to avoid > stalls. In this scenario the userspace daemon was supposed to handle > the majority of OOMs, while the in-kernel OOM killer worked as the > last resort measure to guarantee that the system would never deadlock > on the memory. But this approach creates additional infrastructure > churn: userspace OOM daemon is a separate entity which needs to be > deployed, updated, monitored. A completely different pipeline needs to > be built to monitor both types of OOM events and collect associated > logs. A userspace daemon is more restricted in terms on what data is > available to it. Implementing a daemon which can work reliably under a > heavy memory pressure in the system is also tricky. Thanks for raising this and it is really challenging on very aggressive overcommitted system. The userspace oom-killer needs cpu (or scheduling) and memory guarantees as it needs to run and collect stats to decide who to kill. Even with that, it can still get stuck in some global kernel locks (I remember at Google I have seen their userspace oom-killer which was a thread in borglet stuck on cgroup mutex or kernfs lock or something). Anyways I see a lot of potential of this BPF based oom-killer. Orthogonally I am wondering if we can enable actions other than killing. For example some workloads might prefer to get frozen or migrated away instead of being killed.
