Fedora 32 Looking At Using EarlyOOM By Default To Better Deal With Low Memory Situations

[phoronix]

Phoronix: Fedora 32 Looking At Using EarlyOOM By Default To Better Deal With Low Memory Situations

For months there has been many different discussions over the Linux desktop's poor performance when under memory pressure / out-of-memory type situations. That has resulted in some upstream work so far like GNOME GLib's GMemoryMonitor as well as discussions by distribution vendors about what solutions they could enable today to help the low memory situations. Fedora 32 could begin shipping and using EarlyOOM by default to help in this area...

http://www.phoronix.com/scan.php?page=news_item&px=Fedora-32-Default-EarlyOOM

[k1e0x]

Why not just fix the kernel's OOM killer? Other OS's don't hang up like Linux does in that situation.. Wait.. I know.. systemd-oom-bandaid.

[tildearrow]

Why not disable paging executable code out at all and making it resident on memory at almost all times? Because this may be the cause according to a few users in a former thread.

[Candy]

Wait.. I know.. systemd-oom-bandaid.

Hateword #1 of the past ten years. I bet twenty more to come. 1.3 mio lines for /dev/null

[Britoid]

Why not just fix the kernel's OOM killer? Other OS's don't hang up like Linux does in that situation.. Wait.. I know.. systemd-oom-bandaid.

I actually think systemd is the perfect place for an oom killer.

[cjcox]

Why not just fix the kernel's OOM killer? Other OS's don't hang up like Linux does in that situation.. Wait.. I know.. systemd-oom-bandaid.

It's funny you mention "you know who". Because on our databases when there's a runaway or something that causes the OOM-killer to happen, we lose pieces of systemd. And the only way you can restart systemd is with systemd (which is now non-operational). We end up having to bring our systems down hard and reboot to fix. This is all on CentOS 7.

[Britoid]

It's funny you mention "you know who". Because on our databases when there's a runaway or something that causes the OOM-killer to happen, we lose pieces of systemd. And the only way you can restart systemd is with systemd (which is now non-operational). We end up having to bring our systems down hard and reboot to fix. This is all on CentOS 7.

systemd should remain operational as long as pid 1 is still there, which should never be killed or swapped out.

anything else sounds like a kernel bug.

[Volta]

Fedora 32 is going to be exciting. If they provide Gnome optimization as well it will be awesome.

[Raka555]

Why not disable paging executable code out at all and making it resident on memory at almost all times? Because this may be the cause according to a few users in a former thread.

The problem is those huge dynamic libraries.

[Raka555]

I actually think systemd is the perfect place for an oom killer.

Not sure that systemd (or any init system) really have more information to make a better decision than the kernel.

To me a kind of ok solution would be on a gui desktop to pop up a dialog informing the user about the situation and asking which process to kill (if you can get pass the chicken and egg to actually get something displayed)