Hey, that's me! (suggesting an OOM pardon feature)

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/

I still remember following Andries’s “Linux kernel hacker’s hut” course he taught at the Eindhoven University of Technology (TU/e) back in 2010. Every week we’d get an assignment where we had to write exploits for commonly occurring security vulnerabilities (e.g., buffer overflows, bad printf format). It was one of the most enjoyable courses I ever followed. Thanks for that, Andries!

I confess, this is very funny and the underlying situation is a bit absurd, but it's unclear what point Brouwer is making by pointing out the absurdity.

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?

It's 2026 and I still can't configure the OOM killer to kill firefox before anything else.

FreeBSD has a "protect" command which does something similar to what this asks for – the man page [1] describes it:

"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&...

I never pay for the OOF insurance, it seems like a waste of money and I've never met anyone that's had it happen.

While I have had my time fighting the OOM killer, I believe overcommit would have always won. To torture the metaphor a bit more, airlines have OOF mechanism - they just eject the overcommitted passengers before the plane takes off.

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.

I’d say, let the one who tried to allocate memory crash, and if you’re a critical process like xlock, use statically allocated memory and don’t alloc again.

I know this is not a popular / mainstream position, but I managed a very large fleet of systems this way:

- 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.

undefined

Happy to see this trending, I probably share this in my company's slack once a month.

(2004)

Especially in an era where RAM is so expensive, the obvious answer is to simply never use memory. If your data can't fit in the plethora of CPU registers at your disposal, your software is probably too complicated. /s