On Sat, 2020-07-11 at 14:31 -0300, Sergio Belkin wrote:
> My only question is if measuring memory pressure is a better indication.
> If nohang-desktop uses PSI, isn't it a more proper solution?

The basic problem is that PSI can only be reactive. You need to measure
it over a period of time and then react if matters have turned bad for
long enough. Generally, I believe that you will be looking at reacting
after 10-30s, which is already a really bad situation.

Also, to do this properly, you may want to have different rules
depending on which parts of the system (i.e. systemd unit or cgroup) is
under memory pressure. This requires a few things:

 1. A daemon to monitor cgroups
    (possibly nohang, but realistically you really want systemd-oomd)
 2. A desktop that properly places everything into separate cgroups

Both of these items are work-in-progress areas. It is going to happen,
but we are not quite there yet (KDE is also working it).


Back to the original claim. If PSI requires measuring the pressure over
a period of time, then the reaction will only happen *after* the
situation has turned bad. In general this is a *good* thing, you don't
want to go into panic mode just because the system is sluggish for a
bit. However, it is also *bad*, because the graphical user interface
really should *not* freeze for 10-30s.

This is where the uresourced proposal ("Reserve resources for active
users") that I submitted earlier ties in. It approaches the problem
from the other side, by protecting the core session processes from the
effects of memory pressure[1]. It does so by guaranteeing a memory
allocation of 250MiB to those important processes[2].

By doing this, the UI should remain reasonable responsive even if the
rest of the system is under huge memory pressure and is heavily
thrashing.


So, from my point of view the right thing here is to:

 1. Go with a simple approach for now, because things are changing.
    EarlyOOM probably fits the bill here.
 2. Also consider using uresourced, it is simple and should improve
    things a bit further.
    This only makes sense if KDE is already starting using systemd.
 3. Move to a purely PSI based approach once systemd-oomd comes along.

Benjamin

[1] The KDE systemd startup work is fully compatible. Not sure if that
is merged and usable in Fedora.
[2] From a memory management point of view the kernel basically behaves
as if those processes are using 250MiB less. Which means considerably
less swapping and such for those processes.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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