On Mo, 06.01.20 17:47, Lennart Poettering (mzerqung(a)0pointer.de) wrote:
On Mo, 06.01.20 08:51, Chris Murphy (lists(a)colorremedies.com) wrote:
> On Mon, Jan 6, 2020 at 3:08 AM Lennart Poettering <mzerqung(a)0pointer.de>
> > Looking at the sources very superficially I see a couple of problems:
> > 1. Waking up all the time in 100ms intervals? We generally try to
> > avoid waking the CPU up all the time if nothing happens. Saving
> > power and things.
> I agree. What do you think is a reasonable interval? Given that
> earlyoom won't SIGTERM until both 10% memory free and 10% swap free,
> and that will take at least some seconds, what about an interval of 3
None. Use PSI. It wakes you up only when pressure stalls reach
threshold you declare. Which basically means you never steal the CPUs
on an idle system, you never cause a wakeup whatsoever.
> > But more importantly: are we sure this actually operates the way we
> > should? i.e. PSI is really what should be watched. It is not
> > interesting who uses how much memory and triggering kills on
> > that. What matters is to detect when the system becomes slow due to
> > that, i.e. *latencies* introduced due to memory pressure and that's
> > what PSI is about, and hence what should be used.
> Earlyoom is a short term stop gap while a more sophisticated solution
> is still maturing. That being low-memory-monitor, which does leverage
Yes, l-m-m is great. If we can deploy l-m-m today already, why isn't
it good enoug for earlyoom?
Oops, sorry. I mean GMemoryMonitor. I assumed l-m-m and GMemoryMonitor
was the same thing, but they aren't. I am not sure about l-m-m,
haven't looked at it in detail.
GMemoryMonitor = great
l-m-m = no idea
Lennart Poettering, Berlin