Ubuntu 26.10 changes how the system choose which processes are killed when memory runs low, making a rogue browser tab is less likely to punt you back to

Ubuntu 26.10 changes how the system choose which processes are killed when memory runs low, making a rogue browser tab is less likely to punt you back to the login screen.

When your system runs out of memory, the kernel’s out-of-memory (OOM) killer kicks in, terminating processes to recover some.

The issue is that doesn’t always kill the right things.

By default, many apps and critical desktop services share the same priority score. When the OOM killer is choosing its victim target, it looks at their OOM scores, not “what’s using the most memory”.

Firefox and GNOME Shell, for example, share the same priority status. If memory pressure increases, the OOM killer may decide to terminate GNOME Shell to free up memory rather than the the process causing runaway memory requirements.

I regularly encounter this myself in Ubuntu VMs if I try to do too many things (with too many Firefox tabs open): rather than OOM nuking an app, it kills GNOME Shell instead – but I’d much rather a tab crash than my entire desktop session.

Ubuntu 26.10 makes changes to mitigate this.

Canonical’s Jean Baptiste Lallement says “the goal is simply to preserve the desktop session where possible” by terminating apps before core session services. To do this, it’s lowered the OOM scores for desktop processes so they’re less likely to be nixed.

Ubuntu 26.10 also stops systemd-oomd being able to kill user sessions as it doesn’t use the same OOM priority scores as the kernel, and important desktop services could still be nixed based on memory pressure requirements.

These changes will improve how Ubuntu copes when memory runs out, but Lallement calls it “a first step” that “does not make Ubuntu immune to OOM conditions”. More granular OOM policies for desktop services and apps are planned.

Ubuntu 26.10 is released on Thursday 15 October, 2026, but if you plan to test drive the beta that’s due on Thursday 24 September, these changes will be there – not that you’ll notice them, hopefully!

  • FishFace@piefed.socialEnglish
    6·
    13 hours ago

    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.

    • MonkderVierte@lemmy.zip
      1·
      2 hours ago

      The OOM killer has a much smarter heuristic to deprioritise processes which are being actively used.

      Which is why you’re stuck for 2 minutes, until it’s done it’s decision-making in low-memory. And why i use earlyoom.

      (and why is it yet another systemd-somethingd? Free the service!)

      • FishFace@piefed.socialEnglish
        1·
        2 hours ago

        Do you actually know that the decision-making takes a long time? I would have assumed that it’s pretty quick as it doesn’t need to access much, and what it does need to access should mostly be staying in RAM even when thrashing. But I don’t know that for sure. I had assumed that essentially all the delay was other things happening very slowly, allocating more memory byte by byte before an actual OOM condition was met.

          • FishFace@piefed.socialEnglish
            1·
            2 hours ago

            sure, but how much memory? Here’s how I imagine it working (based on approximately zero knowledge):

            • OOM killer is triggered
            • The kernel code for the OOM killer (including heuristics) has to be swapped in. This code should only be a few KB at most so won’t actually take long.
            • The code has to be executed. To do so it needs to access information about all processes
            • Even if this information can be swapped out, it, likewise, is very small.

            So in my imagination it only takes two small blobs of data being swapped in - if kernel code and process information even can be swapped out; maybe it can be protected. Maybe you know something that ruins this picture though.