I'm from the back-times...

Posted May 1, 2025 16:08 UTC (Thu) by davecb (subscriber, #1574)
In reply to: I'm from the back-times... by ballombe
Parent article: Custom out-of-memory killers in BPF

Yup! I did that on certain production machines I manged in the past.

Mind you, I think an oom-killer is a strange but sometimes good idea. I was looking for possible better algorithms.
Solaris, for example, had a mechanism to cap rss for a process. If it exceeded that, it had to page.

That was one part of a general solution. That particular scheme assumed you knew how much rss to allocate to a program. Sometimes true, sometimes not (:-))

I'm from the back-times...

Posted May 2, 2025 12:49 UTC (Fri) by Sesse (subscriber, #53779) [Link] (1 responses)

You can set LimitRSS= on a systemd service (which uses cgroups to this effect).

I'm from the back-times...

Posted May 2, 2025 20:58 UTC (Fri) by davecb (subscriber, #1574) [Link]

Indeed: if I wanted the limited Solaris functionally, I'd set MemoryHigh=bytes, as per
https://docs.kernel.org/admin-guide/cgroup-v2.html#memory...

Now, how can we improve on that with eBPF? (Hint: I mentioned Teamquest earlier)

--dave

(When I last looked, LimitRSS wasn't implemented on Linux. Also, the ulimit/LimitXXX mechanism is the one that causes the system to return SIGSEGV/EMFILE/EFBIG/SIGXCPU/EAGAIN errors, rather than making it page.

The MemoryXXX functions are
- MemoryMin=bytes, the amount of memory you’re guaranteed. If your usage is below this, you won’t be reclaimed/paged.
- MemoryHigh=bytes, the point at which the system starts penalising the process. If you exceed this, your process will be throttled and memory reclaimed, to avoid it being oom-killed.
- MemoryMax=bytes, the limit. If your process exceeds this, the oom-killer will be called.)