Clear Linux Set To Begin Offering EarlyOOM For Better Dealing With Memory Pressure

[phoronix]

Phoronix: Clear Linux Set To Begin Offering EarlyOOM For Better Dealing With Memory Pressure

Following Fedora's plans to begin using EarlyOOM by default and other recent upstream discussions about Linux's relatively poor performance when it comes to the Linux desktop not handling memory pressure / low RAM situations well, Intel's Clear Linux looks like it will soon offer EarlyOOM as an option...

http://www.phoronix.com/scan.php?page=news_item&px=Clear-Linux-EarlyOOM-Bundle

[tildearrow]

Why are they doing this? Why not try to fix the problem instead? (or besides doing this?)

I feel bad how everybody is going for the workaround and not the solution :<

[flower]

Why are they doing this? Why not try to fix the problem instead? (or besides doing this?)

I feel bad how everybody is going for the workaround and not the solution :<

IMHO earlyoom is mostly needed on desktops.
I wouldn't install it on my arm server with low ram.

But maybe a configurable oom profile in kernel config would be a better solution

[Britoid]

earlyoom is probably going to be shortly lived given apparently an enhanced oomd is going to be merged into systemd.

https://lists.fedoraproject.org/archives/list/[email protected]/message/W73ZVOIRNNW4YVQT6FNSLI6GHUJCZSKY/

[birdie]

earlyoom is probably going to be shortly lived given apparently an enhanced oomd is going to be merged into systemd.

https://lists.fedoraproject.org/arch...SLI6GHUJCZSKY/

That's funny and sad simultaneously. Before the earlyoom proposal no one in Fedora gave an f about this issue and no one worked on including FB's oomd in systemd. Now, when we do have a working solution without any if's Lennart starts opposing to it: "If it's not from me, it's "bad"".

And what's wrong with a 100ms interval in earlyoom? There are systems and situations where this interval is 100% warranted and anything bigger than that will make the system unresponsive before earlyoom has enough time to react.

[tomas]

Why are they doing this? Why not try to fix the problem instead? (or besides doing this?)

I feel bad how everybody is going for the workaround and not the solution :<

And what is the solution? Why do you see this as a workaround?

[grigi]

Making apps actually honour a "low-memory" signal would be extremely useful. e.g. to force a GC run on java apps when memory starts being pressured. Or telling the browser to unload uncompressed images, or defragment its heap, etc...
That would help a LOT for many use cases.
But an early oom would essentially get rid of the system trashing before it starts ooming, which is the worst symptom we have right now. So an easy fix to get rid of the perceived problem.

I say perceived because Linux manages memory much better than other desktop OS'es.
Especially once enabling transparent memory compression that can give one a 10-20% more effective ram which really makes a difference on a lowly 4G system.

[Guest]

Why are they doing this? Why not try to fix the problem instead? (or besides doing this?)

I feel bad how everybody is going for the workaround and not the solution :<

Sometimes, large amounts of memory are an unavoidable requirement for some kinds of work. Users don't necessarily know that when they start such programs or work. For power users, such a thing would be unnecessary and most likely annoying, so as long as it can be disabled, it's fine.

[Guest]

Making apps actually honour a "low-memory" signal would be extremely useful. e.g. to force a GC run on java apps when memory starts being pressured. Or telling the browser to unload uncompressed images, or defragment its heap, etc...

Android has been doing this since v1.0. Honestly, there's no need to reinvent the wheel, and we could just use Android on mobile devices, but without the closed source Google services, and with hardware that has proper open source driver support.

[kokoko3k]

That's funny and sad simultaneously. Before the earlyoom proposal no one in Fedora gave an f about this issue and no one worked on including FB's oomd in systemd. Now, when we do have a working solution without any if's Lennart starts opposing to it: "If it's not from me, it's "bad"".

And what's wrong with a 100ms interval in earlyoom? There are systems and situations where this interval is 100% warranted and anything bigger than that will make the system unresponsive before earlyoom has enough time to react.

No need to hurry, since it lives into memory that is locked/not swappable.