On Fri, Jan 3, 2020 at 11:12 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 [1]? 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 [2][3] 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.
We've been working closely with Alexey, the maintainer of nohang, on
this proposal. He has recommended using either earlyoom or nohang as
the two best choices over other available options (e.g. oomd, or
low-memory-monitor). I'm not completely certain why earlyoom was chosen
over nohang, but I think simplicity and code maturity were likely
important considerations in the final choice.
nohang has experimented with PSI, but it actually isn't using PSI
metrics by default because they've proven to be less effective than
hoped for. In theory, using an interactivity measure like PSI should
provide for the best results, but in practice it just hasn't worked out
well.
In our experiments, low-memory-monitor is currently significantly worse
at handling OOM conditions (as has been noted elsewhere in this
thread). Although we're likely to enable low-memory-monitor in
Workstation, we would use it only for advisory memory pressure
notifications (GMemoryMonitor).
Michael