Resource management for the desktop

For as long as we have had desktop systems, there have been concerns about desktop responsiveness and developers have been working to improve things in that area. Over the years, Linux has gained a number of capabilities — control groups in particular — that are applicable to the problem of improving desktop performance, but use of these features has lagged behind their availability. At the 2020 Linux Plumbers Conference, Benjamin Berg outlined some of the work that is being done by the Linux desktop projects to put recent kernel features to work.

His focus, he began, is on resource management for desktop systems, where the resources in question are CPU time, memory, and I/O bandwidth. Current systems leave applications to compete with each other for these resources, with little supervision. It is possible to favor some applications by adjusting nice (CPU-priority) levels, but such changes take effect at the process level. For the most part, Linux desktop systems are managed at the process level, which is a poor fit to the problem space.

It should be possible to do better than that by making use of the features provided by control groups. Rather than treating processes equally, it is possible to treat users or applications equally, regardless of the number of processes they run. Control groups can also help to make the desktop more responsive; a desktop manager can use them to implement decisions based on factors like the importance of a service, whether a given user is active at the moment, or whether any given application has the focus.

It may be 2020, but problems like thrashing and out-of-memory (OOM) handling still afflict desktop systems. There has been some recent work done to improve this situation; for example, Fedora adopted the earlyoom daemon for the Fedora 32 release. Earlyoom is an example of a "memory-available" approach to the problem; the core idea is to ensure that the system always has enough memory available to hold the files needed by the workload in cache. That prevents the system from paging out (and faulting back in) the executables that the user is currently running. Memory-available approaches have the advantage of being able to use current information; they can poll the amount of available memory multiple times per second if need be.

Another approach uses the pressure-stall information exported by relatively recent kernels. Tools like low-memory-monitor, nohang, and oomd use this information to manage system memory. In one way this is a better approach, Berg said; pressure-stall information is a more reliable way to tell whether the system is thrashing or not. But it's also relatively slow, being calculated every ten seconds or so; that is too slow for a desktop.

Some distributions are also experimenting with faster swapping as a way of improving memory availability; swapping to a zram device can improve the responsiveness of a system, for example. There are lot of approaches being tried in this area, he said.

But there is a fundamental problem: none of these approaches are effective at protecting graphical sessions and ensuring that they have the resources they need. The real goal is to ensure that critical processes like the graphical shell are responsive at all times. Problem applications must be identified and either isolated or killed. Managing available memory on a system-wide basis doesn't get that done.

Using control groups

Control groups can, though. They were designed for just this sort of process containment and control. By using the memory, CPU, and I/O-bandwidth controllers, a desktop manager should be able to contain thrashing and ensure the availability of resources for important processes.

That idea leads to the next question: how should these control groups be managed to create the desired level of process isolation? It turns out that systemd, through its management of control groups, provides the needed capabilities. So the GNOME project, and other desktop environments too, are starting to use it. "Starting" because many of the needed capabilities have only been available for the last year.

Getting there has involved setting up a per-user session bus in the D-Bus subsystem. A lot of fixes have been applied for proper session detection. It was necessary to port GNOME utilities to the systemd API. Tools like gnome-terminal have learned to create a new scope for each tab, providing proper process isolation. The KDE project, among others, is also working on systemd integration.

A set of conventions for the management of desktop sessions within systemd is under development. User sessions are split into three separate control groups:

• session.slice contains the essential session processes — the desktop shell, for example.
• app.slice contains normal applications.
• background.slice contains "irrelevant stuff" like indexing processes or backup operations.

Everything that the user runs ends up in one of those groups. Each application gets its own control group under one of the above; the application ID is then encoded into the associated systemd unit name.

This arrangement allows control-group attributes to be modified on a per-slice or per-application basis; in other words, it is now possible to control resource availability in a per-application way. KDE has taken advantage of this feature to implement a new task manager that shows applications rather than processes. An application may run many processes, but that is not a detail that users are usually concerned about, and the number of processes should not affect the resources available to the application. A similar tool is being created for GNOME, making information on per-application resource usage easily available.

This work is not done, though. More tools still need to be migrated over to the systemd API; xdg-autostart applications are still not handled properly for example. Applications often launch other applications; think about a chat application launching a browser when the user clicks on a link. That browser should end up in its own group, rather than being grouped with the chat application. Applications are "just spawning stuff now"; they need to start making the proper calls to ensure that the grouping is handled correctly. KDE has a working API for this now, he said; the GNOME glib library is being updated as well.

The move to systemd is not complete at this point, and applications often still end up in the wrong control group. But it is "working in most cases" and already quite useful.

uresourced

Getting applications into the correct control groups is a step in the right direction; it ensures that applications compete against each other rather than processes competing. But that is not enough to create a truly responsive desktop; that requires adjusting the resources available to those control groups to implement the desired policy. To that end, he has been working on a resource manager called uresourced that enables and manages the CPU, memory, and I/O controllers for applications.

For example, uresourced tracks who the active user is and allocates 250MB of memory (or 10% of the total available, whichever is lower) to that user; that allocation is given to the session.slice group in particular so that it's available for the most important applications. The active user also gets a larger share of the available CPU time and I/O bandwidth. So applications (rather than processes) are now competing for the CPU, and the active user gets a larger share. The core session processes should be protected from thrashing regardless of the system workload; he confessed that he has yet to find an effective way of testing this behavior, though.

This work is not complete; among other things, the I/O controller is not fully configured. Systemd doesn't yet have all of the necessary options to do this configuration; it can't use the io.cost (formerly io.weight) controller, for example. There are also complications that come up when the system is using the logical volume manager (LVM), which distributions like Fedora do. Adding a new daemon for this task seems excessive as well; Berg expects uresourced to eventually be absorbed into something else. The logical home would be systemd-logind, but it doesn't quite fit there, he said.

For now, though, uresourced will be shipped as part of the Fedora 33 release; Fedora 32 users can also try it out by installing it separately.

Berg wound down with a few remaining questions, starting with whether systemd-oomd (the integration of oomd with systemd) will work well on desktop systems. He hasn't yet tried it, but it seems like it should be able to detect problematic workloads. The real question is how to react when that happens. Options include freezing the offending process and asking the user what to do, simply killing it off, or trying to actively contain it with control-group parameters. For now, there's little to do but to try it out and see how it works.

He wonders whether user sessions are being isolated sufficiently. The use of the CPU, memory, and I/O-bandwidth controllers should be enough to do the job. He worries, though, that the desktop may end up being crippled if the I/O controller does not work well enough. He mentioned again problems that arise when LVM is in use, and the inability to use the io.cost controller. The features provided by the kernel are good, he said, but they may not yet be usable by desktop environments.

What else could be done? One thing would be to prioritize the application that currently has the desktop focus. It should be simple to do, he said; simply find the right control group and set the priorities accordingly. Perhaps some work could be done to save power as well; finding and freezing tasks that perform too many wakeups, for example.

There is clearly a lot of work yet to be done in this area, but it seems that progress is being made. Look for desktop systems to become more responsive in the near future.

The slides from this session [PDF] are available.

Index entries for this article
Conference	Linux Plumbers Conference/2020

---

to post comments