Systemd OOMD Will Now Honor "ManagedOOMPreference" For All cgroups

[phoronix]

Phoronix: Systemd OOMD Will Now Honor "ManagedOOMPreference" For All cgroups

Stemming from Ubuntu 22.04 LTS activating systemd's out-of-memory daemon (systemd-oomd) and users finding their web browser being killed when facing memory or swap pressure, a change has been upstreamed in systemd to help alleviate this situation...

https://www.phoronix.com/news/OOMD-Preference-All-Cgroups

[ResponseWriter]

This is a useful feature I'm surprised has taken so long. Having to set priorities by process ID, as per kernel's oom handling, is just tedious.

Recently on my system while compiling, the not all that RAM heavy kwin_wayland process was killed more than once while a memory-hog like Gwenview or mpv (less of a hog but caches video in RAM) has been open. If not one of those, I'd actually much rather just the browser was killed rather than my entire session!

[Old Grouch]

Given that tabs get their own processes these days, I would like some way of linking the process to the URL and/or HTML header being displayed by the tab so I can choose which memory hog or cpu hog tab to kill, rather than killing the lot.

[tachi]

Killing user's applications without warning is never nice. I'm surprised there isn't an interface to tell the desktop environment to show a message that the system is under high memory pressure and something is going to get killed soon (like Windows does)

[bobbie424242]

OOM management is dead hot tech largely worthy to obsess about !
Please make your system go OOM now ! If you don't, you are missing out incredible features.

[Linuxxx]

How come Fedora (Red Hat) hasn't noticed & fixed this already, given that they were the first adapter of systemd-oomd?

Why did it even need for Canonical to step-up and fix the Linux desktop yet again?

[ireri]

How come Fedora (Red Hat) hasn't noticed & fixed this already, given that they were the first adapter of systemd-oomd?

Why did it even need for Canonical to step-up and fix the Linux desktop yet again?

Because nobody uses Fe…

=P

Jokes aside, this patch sounds like a band-aid to me. Can't there be an OOM daemon that kills whatever is actually causing the mess?

Like, by measuring how memory straining a process have been in the last [lapse of time] and weight it against how long has it been using the CPU or something?, anything a bit smarter than trying to foretell what cgroups would be more important than others before even knowing who will be using the computer or what kind of usage it will have for this reboot.

[JacekJagosz]

Because nobody uses Fe…

=P

Jokes aside, this patch sounds like a band-aid to me. Can't there be an OOM daemon that kills whatever is actually causing the mess?

Like, by measuring how memory straining a process have been in the last [lapse of time] and weight it against how long has it been using the CPU or something?, anything a bit smarter than trying to foretell what cgroups would be more important than others before even knowing who will be using the computer or what kind of usage it will have for this reboot.

I don't think that makes sense actually. Because what if you are doing fluid flow calculations, or compiling in the background. Then those apps are the memory hogs, but you don't want to get them killed, right?
To me it is crazy that lowmemorykiller introduced in Android so long ago seems so much more intelligent about killing apps, where the "compositor" knows which apps are in the foreground, and how long ago they were used, and then adjusts `oom_score_adj` for each app. This already seems so much better, and even that isn't the newest solution, this has already been superseded by `lkmd` that runs as a user process, and can take even more things into configuration. How is Linux so much behind?

[edgmnt]

Killing user's applications without warning is never nice. I'm surprised there isn't an interface to tell the desktop environment to show a message that the system is under high memory pressure and something is going to get killed soon (like Windows does)

I guess memory usage excursions could happen pretty quickly, but why not pause memory hogs once a limit is hit and ask the user to intervene and pick something to kill? I feel like it should be possible with a bit of reserved RAM, much like filesystems reserve space for root.

Maybe it can also be done cooperatively, giving the apps a chance to slow down or at least save state. Although at this point maybe our apps should be made crash-safe and quick to resume after killing.

[ATLief]

With how abundant storage is these days I don't see why any process should be automatically killed instead of having its memory swapped to disk, unless there isn't any dedicated swap area or the process is clearly malfunctioning. Better to decrease performance than risk losing any unsaved work.