Ubuntu Deciding How To Tame Their systemd-oomd Killing Experience

[phoronix]

Phoronix: Ubuntu Deciding How To Tame Their systemd-oomd Killing Experience

One of the many changes with the recent Ubuntu 22.04 LTS release was enabling systemd-oomd by default as the out-of-memory daemon that can kill processes when under memory pressure. Unfortunately, for some users this has led to a poor desktop experience with finding their applications being unexpectedly killed. Ubuntu developers are now discussing how to improve this OOMD handling...

https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-systemd-oomd-Headaches

[skeevy420]

I think there's a 4.5 or 5th option of a dynamic swap file framework. Let it start at 1GB but let it double in size if 50% is reached. Like, once 512mb of swap is used then double the available swap 1GB to 2GB just in case; if 1GB is hit then double it to 4GB; so on and so forth until the hypothetical MaxDynamicSwapSizeGB=20 is hit. Every time swap hits 10% or less size used it'll go down in half until MinDynamicSwapSizeGB=1 is reached.

But, yeah, my solution in the other thread was to bump it from 90% to 99%. That and an increase in swap size are the only realistic options.

[Henk717]

I don't understand why distro's do not take a page out of Windows's book and preinstall something like swapspace. I am the kind of user who occationally needs more ram than I have so I need some swap. But its rare and I don't always know how much. So swapspace helps me do just that, it monitors the ram usage and if things get dire it begins creating swap files accordingly. So my system doesn't have swap by default but in those rare cases i can trust they get created. A while after i am done the tool detects they aren't being used and cleans up after itself removing all the swap files entirely making my system a swap free system again.

Its the best of both worlds since your stuff never gets killed, for most users you never have disk space taken up and you don't need to configure anything so installers do not even have to prompt the user any kind of swap question. It just works.

[om26er]

Great. I have seen the new OOM killer the whole gnome-session when things get crazy. I hope it would first kill apps before coming to killing the session itself.

[hax0r]

One of many reasons I don't use systemd and use OpenRC on Gentoo instead, I don't use any of the OOM deamons crap to mitigate low memory scenarios, vanilla Linux is really bad at handling near OOM scenarios, hard to believe that throughout all these years and in 2022 upstream linux does not have a good heuristics to deal with OOM, everybody knows how bad Linux is with page trashing, high latency, high load in near OOM conditions.

I only use the excellent 'mm: protect mappings under memory pressure' patch to prevent thrashing, avoid high latency and prevent livelock in near-OOM conditions https://gitlab.com/sirlucjan/kernel-...pressure.patch

Everybody knows about systemd '90 seconds timeout countdown' driving them crazy.

[mSparks]

have they tried turning it off and on again?

[archsway]

earlyoom seems to be better behaved than systemd-oomd for me. Typical that the systemd replacement would not work as well.

[skeevy420]

have they tried turning it off and on again?

because I have to type something

[birdie]

earlyoom seems to be better behaved than systemd-oomd for me. Typical that the systemd replacement would not work as well.

Yeah, I'm on fedora and I continue to use earlyoom instead of systemd-oomd.

[QwertyChouskie]

One of many reasons I don't use systemd and use OpenRC on Gentoo instead, I don't use any of the OOM deamons crap to mitigate low memory scenarios, vanilla Linux is really bad at handling near OOM scenarios, hard to believe that throughout all these years and in 2022 upstream linux does not have a good heuristics to deal with OOM, everybody knows how bad Linux is with page trashing, high latency, high load in near OOM conditions.

I only use the excellent 'mm: protect mappings under memory pressure' patch to prevent thrashing, avoid high latency and prevent livelock in near-OOM conditions https://gitlab.com/sirlucjan/kernel-...pressure.patch

Everybody knows about systemd '90 seconds timeout countdown' driving them crazy.

That patch looks interesting, do you know if there's any effort around upstreaming it?