Isn’t this article essentially wrong because of this line: Ubuntu 26.10 also stops systemd-oomd being able to kill user sessions systemd-oomd works completely differently from the kernel OOM killer. Unless it’s changed, it just ranks everything by how much memory they’re using and picks the biggest memory hog that isn’t manually deprioritised by some config rule, and kills that. The OOM killer has a much smarter heuristic to deprioritise processes which are being actively used. As far as I understand, systemd-oomd was always a shoddy implementation because of this, and when it first started being used in Fedora (I don’t know about Ubuntu) also had insanely aggressive settings so that it would nobble something when you still had 20% free memory. The problem it was trying to solve was that Linux’s behaviour under memory pressure is actually abysmal. I have no idea if other OSes are any better, but basically once your computer starts thrashing, you’re better off rebooting it because it’ll be up again in a minute, whereas if you wait it’ll probably be half an hour if you’re lucky. The OOM killer detects actual out-of-memory, not thrashing, and so you can spend days slowly grinding your way through operations that should have taken seconds without ever triggering it. Hence systemd-oomd is designed to kick in before you actually run out of memory… and as a consequence it somewhat frequently does so too early.