Re: Reserve resources for active users (Workstation) - Fedora 33 Self-Contained Change proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>oomd (or rather systemd-oomd) and will make heavy use of cgroups to work well

Other side of this is high CPU usage: https://github.com/facebookincubator/oomd/issues/79

сб, 11 июл. 2020 г. в 17:34, Benjamin Berg <bberg@xxxxxxxxxx>:
On Sat, 2020-07-11 at 08:43 +0200, Igor Raits wrote:
> On Fri, 2020-07-10 at 15:55 -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS
> >
> > == Summary ==
> > This proposal adds cgroup based resource protections for the active
> > graphical session. This is done by passing a memory protection of
> > 250MiB to active users (capped at 10% of system memory) and by
> > enabling other cgroup controllers (CPU, IO) to ensure important
> > session processes get the resources they need.
>
> Just curious, why 250MiB and not some other number?

Initially, it was an educated guess (i.e. it seemed low enough to be
reasonable and high enough to be useful).

I then continued to do a bit of experimentation and found that my
gnome-shell would stop page-faulting quite a lot if I gave the session
processes >=350MiB of memory (measured by manually setting memory.max
and using "perf trace -F -p X").

Tejun suggests it is sufficient to protect around 50-75% of the
required memory, so 250MiB still seemed like a reasonable value after
those tests.

Note that it is easy to change, simpliy modify /etc/uresourced.conf
(and, ideally reboot to ensure it is properly applied to your user
session).

> > See: https://pagure.io/fedora-workstation/issue/154
> >
> > == Owner ==
> > * Name: [[User:benzea|Benjamin Berg]]
> > * Email: bberg@xxxxxxxxxx
> > * Product: Workstation
> > * Responsible WG: Workstation
> >
> >
> > == Detailed Description ==
> > Graphical sessions should always be responsive, even when the
> > machine
> > is doing a lot work or in the extreme case has started to thrash.
> > We
> > have started to ship EarlyOOM with F32, however, while it is a good
> > solution to this date, it is shipped with the understanding of
> > being
> > superseded by other approaches in the future.
>
> Does it mean we do not ship earlyoom anymore or what is this sentence
> supposed to indicate?

EarlyOOM is still very useful today. However, from my point of view,
EarlyOOM is just an intermediate measure until a more advanced solution
is implemented and can be rolled out to users. This solution will be
based on oomd (or rather systemd-oomd) and will make heavy use of
cgroups to work well.

This is a longer path, shipping uresourced puts us a step further down
that road.

> [SNIP]

Benjamin
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux