#2320 F32 System-Wide Change: Enable EarlyOOM
Opened 7 days ago by bcotton. Modified 21 hours ago

Install earlyoom package, and enable it by default. If both RAM and swap go below 10% free, earlyoom issues SIGTERM to the process with the largest oom_score. If both RAM and swap go below 5% free, earlyoom issues SIGKILL to the process with the largest oom_score. The idea is to recover from out of memory situations sooner, rather than the typical complete system hang in which the user has no other choice but to force power off.

(Note that some discussion is still happening on devel list)

(Note that some discussion is still happening on devel list)

Some? :sweat_smile:

My opinion: I've read most of the discussion on the devel list, and I'm not so sure that enabling this by default is a good idea.

Less than 10% of both RAM and swap free seems both too high and too low a bar. For example, assume 16 or 32 GBs of memory, which means 16 or 32 GBs of swap, the way anaconda sets things up by default. So, 10% of 16 or 32 gigs of RAM is still a lot of free memory, but 15-30 gigs of swap usage is definitely bad. So I think these heuristics need to either be tweaked, or anaconda must stop asking for such big swap partitions.

Also, with both oomd / earlyoom / etc. still being actively developed and tweaked (and with an oom "killer" of some form or shape to be integrated into systemd within the next 1-2 years), I think it's safer to leave this as an optional feature until at least most of the issues have been worked out.

I'm ok with workstation working group enabling it, but yeah, it seems like things are moving around a lot in development here and we have lived without it for this long, so perhaps it's better to wait? But I wouldn't stop them from doing it if they would really like to. I'd keep it off in other install paths for now.

I would prefer to have a self-contained change introducing earlyoom to Fedora before having a system-wide change enabling it by default.

This would give it more publicity and some user base, especially from people struggling with memory limits. These are more likely to read release notes. But it wouldn't change anything for people who have never thought about this topic before and are not interested in understanding what and how oom does to their system.

I am mostly concerned that we need to somehow educate and give a heads-up for the user experiencing OOM event that it ends in responsive but inconsistent state of the system. That it needs some attention. And currently there is nothing in earlyoom service which solves it.

We can work on consistency topic, through Killmode and OOMPolicy-like options and cgroups scopes for desktop services and processes, but we are far from done there.

Workstation working group discussed this in today's meeting. Summary: WG supports earlyoom enabled by default for Fedora Workstation 32 (+1:4, 0:4, -1:1)

Metadata Update from @dcantrel:
- Issue tagged with: meeting

21 hours ago

Login to comment on this ticket.