On Fri, Jan 3, 2020 at 4:13 PM Tom Seewald <tseewald(a)gmail.com> wrote:
I think this would be a really big improvement for workstation and other desktop spins,
the handling of out of memory situations have been a consistent paint point on Linux.
However, may I ask why EarlyOOM was chosen over something like NoHang ?
The developer/maintainer of nohang (hakavlad) recommended earlyoom.
I am a bit concerned that EarlyOOM's heuristics may be too
coarse, as it does not take into account the newly-added PSI metrics  that other
projects like NoHang, oomd, and low-memory-monitor utilize. For example, if the system is
thrashing, but swap is not full, to my knowledge EarlyOOM will not see a problem, however
it would be visible via PSI.
Yep, I wonder about this myself and mention it in the two issues we're
tracking. It's likely true that there will be workloads where earlyoom
doesn't help, but equally important is it doesn't make things worse
(or really weird). It's a complicated problem, and part of the
challenge is how to go about making an incremental improvement while
We also have another issue, #120, to look at making swap smaller,
which absolutely exacerbates the swap thrashing problem. Once a system
is swap thrashing, responsiveness is already cratering.
To be clear, I'd rather have something in time for 32 to improve
OOM handling than wait several release cycles for the ideal solution to be ready. I'm
simply curious about what problems, if any, were encountered with the other potential
Those discussions you'll find in #98, including oomd and low-memory-monitor.