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. It does so by guaranteeing a memory allocation of 250MiB to those important processes. 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  The KDE systemd startup work is fully compatible. Not sure if that is merged and usable in Fedora.  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.
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- email@example.com 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://firstname.lastname@example.org