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

[halo9en]

In general I hate that the amount of dirty buffers scales with the amount of memory that you have.
I now always run with the follow settings in my /etc/sysctl.conf:
vm.dirty_bytes = 16777216
vm.dirty_background_bytes = 4194304

I never have any issues while copying large files any more.

Thanks! It really made a huge difference while moving a 10 GB directory (before: frozen desktop, after: can use all sorts of programs while files are being moved).

Btw beware of tlp's defaults: https://www.mail-archive.com/kernel-...msg359847.html

[ferry]

The whole idea of OOM is wrong. The user doesn't want his process killed. When building a distribution with Yocto I want it built, even if it tries to build gcc and nodejs each with 8 threads simultaneously on a quad core + HT cpu.

What actually needs to be done is restrict the number of swapin. This can in theory be implemented in the scheduler.

That this will work can easily be verified by stopping (SIGSTOP) the offending process. It will get swapped out by the remaining processes, but not swapped in again and everything will return to normal. SIGCONT will continue it again.

Of course the process needs to be allowed to run longer then the swapin time needed.

[rastersoft]

1. https://github.com/rfjakob/earlyoom earlyoom
2. https://github.com/hakavlad/nohang nohang
3. https://github.com/facebookincubator/oomd oomd
4. https://gitlab.freedesktop.org/hades...emory-monitor/ low-memory-monitor

Mmmm... when you said there were at least four, I presumed that you talked about low memory monitors, but only the fourth is that; the other three are OOM Killers, which should be just a "last resource" option. Before doing that, all and every application in the system should have the opportunity of freeing some non-critical memory, and for that, only the fourth one is useful...

[caligula]

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.

Isn't this already possible. Mount a ramfs, copy /bin directories, mount over existing /bin ?

[mskarbek]

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.

Take a look at this presentation form All Systems Go! 2019: https://www.youtube.com/watch?v=S0WqoD2_tVs

[Raka555]

Linux has nasty problem of paging everything out on disk IO. My dev system has 32GiB RAM, copying somewhat around 100GiB from one HDD to another via NTFS-3g after half a hour made system barely usable, it still had considirable amount of free and usable mem (around 16GB), but desktop processes have been paged out.

You can try what I mentioned in post #13 of this thread and see if it helps.
I am pretty sure it will fix your problem.

[Britoid]

halo9en They are working on that as well. Or working around since the problems are kernel related.
https://gitlab.gnome.org/GNOME/mutte...e_requests/923

How would this help compared to the current realtime flag?

[birdie]

Four???? Can you point me to them? (just curiosity)

1. https://github.com/rfjakob/earlyoom earlyoom
2. https://github.com/hakavlad/nohang nohang
3. https://github.com/facebookincubator/oomd oomd
4. https://gitlab.freedesktop.org/hades...emory-monitor/ low-memory-monitor

[halo9en]

halo9en They are working on that as well. Or working around since the problems are kernel related.
https://gitlab.gnome.org/GNOME/mutte...e_requests/923

And those workarounds would be gtk specific (mutter), while as you said the problems are kernel related.

[rastersoft]

We need a solution which works without user intervention. The kernel could be the best place for this feature but kernel developers seem not to care about this issue as much as it's crucial and now we already have at least four user space daemons for the task.

Four???? Can you point me to them? (just curiosity)