On Mon, Jan 6, 2020 at 5:47 pm, Lennart Poettering
<mzerq...@0pointer.de> wrote:
Yes, l-m-m is great. If we can deploy l-m-m today already, why isn't
it good enoug for earlyoom?
GMemoryMonitor is the GLib API that's implemented using
low-memory-monitor's D-Bus API.
In practice, using it for OOM killing is not that great, though. We've
rejected this approach because the OOM killing is causing serious
problems and there are no plans to fix it:
https://gitlab.freedesktop.org/hadess/low-memory-monitor/issues/8.
Therefore most likely we'll use l-m-m only for advisory memory pressure
notifications.
On Mon, Jan 6, 2020 at 5:47 pm, Lennart Poettering
<mzerq...@0pointer.de> wrote:
Sounds like someone needs to do their homework, if this is "unclear"?
I mean, you basically admit here that this isn't really figured out to
the end. Maybe let's give this a bit more time and figure things out a
bit more, instead of rushing earlyoom in?
Adopting something now, at a point we already clearly know that PSI is
how this should be done sounds very wrong to me.
I think it would absolutely be reasonable to defer from F32 -> F33 if
we have concrete plans to use that delay to implement an OOM solution.
E.g. if you or someone else wanted to throw together a systemd-level
solution:
Sounds like something that is relatively easily implementable in
systemd though, in a much better way, i.e. hooked to PSI...
I mean, wouldn't this all be solved much nicer, much more future
proof, if someone would just do what l-m-m does as part of systemd
service management, i.e. let's say an option StopOnMemoryPressure=
that watches PSI and terminates services *cleanly* when needed,
i.e. goes through ExecStop= and such?
And you know what, PSI is precisely defined to be used for purposes
like this, we already have experience with it (see l-m-m) and a patch
adding this to systemd isn#t really that hard either...
So again, the problem with PSI so far is that we haven't gotten it to
work well. If systemd can make it work well, that would be super
lovely. Sounds like that would also avoid continuous wakeups, which
would be very nice.
I don't think anybody would object to a systemd-level solution. If it's
part of systemd, there would no longer be concerns about architecture
or code quality, and it'd feel much less hackish. We would want to test
it to ensure responsiveness is comparable to what earlyoom would offer,
of course.
Michael
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
