Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)

sedatk

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.

rwmj

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

EdSchouten

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!

lelandfe

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.

hyperpape

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?

bastawhiz

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

ptx

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

nemothekid

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.

lokar

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.

mad_vill

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