Ubuntu Developers Have An Idea For Handling The Over-Eager Systemd OOMD App Killing

[sinepgib]

For those screaming "just buy more RAM": ugh. It's tiresome to read the same dumb crap again and again.

WRT the actual problem, it seems to me it's poorly configured, and I agree with the sentiment that this functionality is mostly useful in a server anyway, where the user is expected to properly tune this kind of daemon or keep it disabled if unwilling. Normal users won't take the time to say "hmmmmm maybe this particular app should be allowed to use much more RAM than this particular other app", app by app.

[ssokolow]

But is there anough memory for it to put the dialog on screen?

Unlike with the kernel OOM killer, these kinds of killers kick in early, so it's not difficult for them to promise "at least X amount of RAM will be available for you to display your prompt".

[deve]

Seems to me a solution to a non-problem. I mean memory is cheap and plentiful. If you experience out-of-memory problems, your machine isn't configured properly for the use case. Don't get it .

I rarely experience out-of-memory problems, but last time it was due to a bug in kwin_wayland when I opened it in a window and I was testing something in a wayland session. After ~30 seconds it ate my whole RAM and it was hard to close that window because whole gnome session became unresponsible.

The second case was indeed "machine isn't configured properly for the use case" because I was building LineageOS on machine with 8GB RAM and they increased memory requirements to 16GB. Compilation just failed after several hours, so not really a problem anyway.

[andyprough]

systemd + oomd + snapd + gnome, what a disastrous mess. Not only that, but the combination inherently uses far more memory than needed.

Simplify. Use a distro like Void that gives you all you need with far less overhead and complexity.

Also, I agree with the poster who said Ubuntu users should be downloading more ram from the internet. But be sure and download your ram from a trusted source, like IBM/RedHat or Microsoft or Google. Or from Facebook or Twitter. Someone who respects Trusted Computing.

[ehofman]

Lol no. Most developers don't know and don't care. Besides, in the end they couldn't know, the amount of memory available is only known at runtime. They can only set minimum requirements and hope.

Well in such cases Ubuntu or RedHat could provide patches or press to handle these situations.

[sinepgib]

Well in such cases Ubuntu or RedHat could provide patches or press to handle these situations.

Those cases are most cases, and many of those are proprietary anyway. Ubuntu and RH don't really have the strength to press on the consumer segment, as they're the weakest players there. They try to negotiate and it ends in "ok we were just leaving enjoy your three users".
In the server and embedded market developers have better information about resources and are in charge of fixing the program, so where those companies actually do have a say the problem is pretty much moot anyway.

[sinepgib]

Unlike with the kernel OOM killer, these kinds of killers kick in early, so it's not difficult for them to promise "at least X amount of RAM will be available for you to display your prompt".

Fair enough, I thought it was meant as a replacement for the eager reclaiming. What happens in the "let it sit" case, tho?

[remenic]

This sounds like a group of students trying to find a solution to a problem that should have been solved a decade ago, and I honestly can't imagine it isn't. How come this affects Linux so much?

[binarybanana]

Pfff, n00bs. Just get a faster internet connection and download more RAM.

You joke, but Linux supports swap files over nfs, so technically this is indeed possible. if that swap file were on a ramdisk/zram or fast NVMe on the other end it might even be useable. Never tested it, though.

I have 32GB of ram and OOMD killed Firefox yesterday. I had a few GB sized archives open, FF+10 tabs, 3 Dolphin tabs, Gwenview, KCalc, and Kate. During that I started backing up some files to a Zstd-19 compressed directory where ZFS ballooned its memory usage and instead of ZFS giving its memory back like ZFS normally does, OOMD decided to kill Firefox.

That was the first time that OOMD killed a running process on my system. Pissed me right off.



There is one. I don't know if the blame is OpenZFS or OOMD, but there is a problem. ZFS is supposed to give up memory when other programs request it. OOMD kills shit faster than ZFS can make that decision. Instead of ZFS going "Whoops, my bad, didn't mean to be so greedy. Here's some ram." Firefox gets killed.

Problem is zfs on Linux doesn't integrate with the normal page cache. It uses its own cache pool. While it should be able to adjust dynamically it might not be hooked up in all the relevant code paths in the same way as the regular page cache. Maybe it even just periodically frees some memory if memory pressure exceeds some value. i don't know exactly what it does, maybe it's smarter than this worst-case but it'll probably never work as well as in-tree file systems without major rework which would hurt portability.

[sinepgib]

This sounds like a group of students trying to find a solution to a problem that should have been solved a decade ago, and I honestly can't imagine it isn't. How come this affects Linux so much?

All problems are trivial when you are not in charge of solving them