El sáb., 11 jul. 2020 a las 16:39, Benjamin Berg (<bb...@redhat.com>)
escribió:
> 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-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
>
Thanks Chris and Benjamin, I love this kind of constructive discussions :)
--
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
_______________________________________________
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
