[fpoling]

Java allowed to handle out-of-memory rather well if one wanted to even 25 years ago. Basically one allocated a buffer on a startup taking 5% of memory that the application was supposed to use and made all threads to catch the oom exception. When handling that the buffer would be released, GC would be forced and a special flag would be set asking app to cancel any memory-intensive tasks until enough memory would be released and the buffer can be allocated again. It worked extremely well.

[zbentley]

Yeah, crash ballast is an extremely underrated tool.

It also works for the OOM killer: run a daemon with a child process that holds some fixed amount of memory. Adjust OOM scores of everything else on the system lower than the child. If the parent’s waitpid() returns due to an OOM kill, send an alert/shutdown nonessentials/sync buffers to disk and so on.

[man8alexd]

Maybe you should skip running a useless child process and just use PSI to monitor memory pressure.

[zbentley]

PSI polling is also good, but there’s no substitute for knowing for sure that the OOM killer is awake and hunting.

[man8alexd]

You can't know when the OOM killer is awake and hunting. The kernel doesn't know that.

[zbentley]

The approach I originally described provides a useful early warning system for that condition. It’s not perfect, but has proven useful and better than nothing many times.