Reserve resources for active users (Workstation)
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.
- Name: Benjamin Berg
- Email: email@example.com
- Product: Workstation
- Responsible WG: Workstation
- Targeted release: Fedora 33
- Last updated: 2020-08-07
- FESCo issue: #2457
- Tracker bug: #1867216
- Release notes tracker: #547
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.
uresourced a small daemon was written that enables protection of the graphical user session. It serves the following main purposes:
- Safely modify existing GNOME systemd units to closer adhere to https://systemd.io/DESKTOP_ENVIRONMENTS/ (until this is merged upstream).
- Enables the CPU and IO cgroup controllers for users to prevent e.g. fork bombs from taking over the system.
- Allocates a memory guarantee for any *active* user which is distributed to core session processes.
Precautions are in place to not negatively affect systems:
- Active users will receive a protected memory allocation of 250MiB allocation, but capped at 10% of system memory. So low memory systems should not be negatively impacted. Said differently, the memory subsystem treats the core session processes in comparison to everything else as if they were using 250MiB less than they actually are.
uresourceddetects whether the user session is using systemd to prevent passing memory guarantees to processes that are not important (e.g. not a GNOME session).
- Enabling the IO controller has no effect on Fedora currently.
uresourcedis designed to be obsoleted. Everything it does should be absorbed by other upstreams. However, it is a good and safe solution that eases development and permits shipping the benefits to users now.
- Enabling the cgroup controllers may slightly increase the scheduling overhead that the kernel imposes. I don't have numbers right now, but expect this to be <=1% of overall system CPU time.
Benefit to Fedora
This change proposal will improve interactivity of graphical sessions in certain situations. It also is an important step on the path to reap the benefits of systemd and cgroups in workstation scenarios.
- Proposal owners:
uresourcedon workstations by default * Add a preset to enable
- Other developers: no further changes are needed
- Release engineering:  (a check of an impact with Release Engineering is needed)
- Policies and guidelines: N/A (not needed)
- Trademark approval: N/A (not needed for this Change)
No impact. The worst case scenario is that the feature will not be enabled.
How To Test
Testing this has multiple aspects. From the technical side, a test is as simple as:
- Install and enable
- Reboot (to make absolutely sure the user session has picked up all changes, logout may *not* be sufficient)
- Check values in
/firstname.lastname@example.org/session.slice/memory.low(should usually be 250MiB with the default configuration).
- Verify that the allocation is zero if the user is not active on any seat (e.g. switch to GDM and log in via SSH or by doing a
sleep 10; cat ...and coming back).
- Check enabled controllers in
cpu io memory pids).
Beyond that, a test can be done to show that the cgroup kernel controllers are actually beneficial in various scenarios. Possible examples are:
- Running mprime (http://www.mersenne.org/ftp_root/gimps/p95v298b6.linux64.tar.gz); choose local stress test, repeat by selecting 15
NOTE: mcatanzaro has reported a huge impact, with both the session remaining mostly responsive and EarlyOOM not kicking in (EarlyOOM not kicking in is odd, there might be other relevant factors to reproduce). The proposal owners have not been able to reproduce this corner case so far.
- Log in two user A and B (same seat), run
stress-ng -c NCPUSin both. Switch between them and look at
topto verify that the active user gets a 5 times higher CPU share overall.
See other sections.
There are no further dependencies.
- Contingency mechanism: Remove uresourced from the default install set and possibly also remove the preset again
- Contingency deadline: Final freeze
- Blocks release? No
- Blocks product? -
Upstream is identical to the change owner. The upstream repository has a further README https://gitlab.freedesktop.org/benzea/uresourced (which should not contain any more information than what is here).