Hey fellow TU/e'er :) I followed his course as well, somewhere around 2004/5. Executing man in the middle attacks, writing buffer overflow exploits. Good memories!

I looked into this, and actually, it seems like maybe you can? https://man7.org/linux/man-pages/man5/proc_pid_oom_score_adj...

So, in actuality, I think your assertion just taught us all something, because despite knowing that the OOM killer and that the Magic SysRq key[1] exists, I didn't know you could configure this as an input!

[1]: https://en.wikipedia.org/wiki/Magic_SysRq_key

I always wanted it to target java processes, as they were always the culprit. These days it's python, VSCode, and antigravity.

This. It's always browser running amok. I configured win+k shortcut key to: killall -9 chrome

Maybe not in kernel, but running the earlyoom daemon will let you do exactly that in userspace.

It's not a panacea, but in my case setting browser.tabs.unloadOnLowMemory in about:config helped a bunch.

It can only happen once anyway, and I fly weekly!

I read him as arguing that overcommit was a mistake. Of course, he doesn't answer any of the obvious follow-up questions, such as, does fork–exec copy all the process's memory and then immediately throw it away, or what. (One could argue that fork–exec was also a mistake, but it long predates Linux, so this doesn't answer the question of how Torvalds should have designed it.)

The point is that the OOM killer shouldn't exist and arguing about how to tweak it is addressing the wrong problem

Statically allocated memory can still OOM on access, due to overcommit and lazy page table population. What you really want is mlockall(2) (probably with MCL_CURRENT|MCL_ONFAULT followed by madvise with MADV_POPULATE_*)

> if you’re a critical process like xlock, use statically allocated memory and don’t alloc again.

This doesn't save you if someone other allocates and OOM killer chooses you as victim

This is only a viable answer when overcommit is disabled. The problem comes when overcommit is enabled and you find yourself in a position where many programs think they already have memory and yet there is none to give them. If you simply kill the first piece of code that encounters the end of available memory you might take down anything including the kernel itself.

Nothing like statically allocating memory can work when overcommit is enabled because the kernel is free to compress memory, page it out and etc. and then murder you the next time you try to perform any operation that it doesn't have the space for, no matter how safe and static your initialization was.

Note that overcommit is very useful in many cases including the ones where swap saves the stability of the system under conditions that would otherwise completely lock up or panic, so it's also not viable to just prevent it from being used.

The fact that xlock crashing unlocks an X11 session is, IMO, pathetic.

I see you are an AMD VCACHE enjoyer.

Thanks. I was confused for a bit, given these days you can do

    echo "-1000" > /proc/<pid>/oom_score_adj

https://github.com/torvalds/linux/blob/master/include/uapi/l...