It's a funny reply. But what was not funny was the OOM killer killing my screen locker.

Joke all you want, but 22 years later I still stand by that I'd rather get a kernel panic than kill the screen lock.

These days you can do oom score adjusting, which is not as strong as a pardon. I may be taking too much credit, and may misremember the timeline, but I feel like someone took my crappy kernel patch and went "fine, I'll do it the right way", merged that oom score adjusting maybe a year or so later.

Here's an LWN article about it, too: https://lwn.net/Articles/104179/

There surely is something absurd about having to register specific processes as exempt from the OOM killer. But given that the OOM killer exists, and could kill xlock...how should that be fixed?

"The protect command is used to mark processes as protected. The kernel does not kill protected processes when swap space is exhausted. [...] If you protect a runaway process that allocates all memory the system will deadlock."

[1] https://man.freebsd.org/cgi/man.cgi?query=protect&apropos=0&...

A passenger buying a ticket is malloc(), but passengers don't always utilize the seat (use the memory). Normally this works out fine, but occasionally, there are too many passengers. Thankfully though instead of executing a couple passengers they give you a voucher.

- no system swap

- enough memory for core system services set aside in a cgroup for them to use

- by default, all prod service binaries load all code pages into ram at start, and lock them in (no paging out code pages at runtime)

- if needed (rare) services can mount some swap in their own cgroup, but very much discouraged

You need to know how much ram you are going to use, and actually stick to that. Very little is wasted in practice, and you don't have to deal with OOMs all the time. Everything is much more predictable.