I’m not sure what this comic is trying to say but in my recent experience a single misbehaving website can still consume all available swap at which point Linux will sometimes completely lock up for many minutes before the out-of-memory killer decides what to kill - and then sometimes it still kills the desktop environment instead of the browser.
(I do know how to use oom_adj; I’m talking about the default configuration on popular desktop distros.)
https://www.baeldung.com/linux/memory-overcommitment-oom-killer looks like an informative recent article on the subject, and reminds me that my knowledge is a bit outdated. (TIL about the choom(1) command which was added to util-linux in 2018 as an alternative to manipulating things in /proc directly…)
I’m not sure what this comic is trying to say but in my recent experience a single misbehaving website can still consume all available swap at which point Linux will sometimes completely lock up for many minutes before the out-of-memory killer decides what to kill - and then sometimes it still kills the desktop environment instead of the browser.
(I do know how to use
oom_adj; I’m talking about the default configuration on popular desktop distros.)Real, happened too many times to me. What’s that about configuring the OOM, can you give it priorities?
The canonical documentation is https://www.kernel.org/doc/Documentation/filesystems/proc.rst (ctrl-f
oom) but if you search a bit you’ll find various guides that might be easier to digest.https://www.baeldung.com/linux/memory-overcommitment-oom-killer looks like an informative recent article on the subject, and reminds me that my knowledge is a bit outdated. (TIL about the choom(1) command which was added to util-linux in 2018 as an alternative to manipulating things in
/procdirectly…)https://dev.to/rrampage/surviving-the-linux-oom-killer-2ki9 from 2018 might also be worth reading.
How to make your adjustments persist for a given desktop application is left as an exercise to the reader :)