GSoC 2021 · Part IV - Final Review

Overview

For the past 10 weeks, I have been working on implementing active resource management in GNOME as a part of Google Summer of Code 2021. On the surface level, this entailed setting up mechanisms to track states of different applications and then making allocation decisions based on this information. To give a brief idea about my contributions throughout this period I have presented them in the form of tasks along with relevant code and their current status.

Work Product - Task List

Task 1 - Creating a GNOME extension

My first task was to track the active or currently open window in gnome-shell and allocate more CPU weight to it. After discussing with my mentors I built an extension which on getting notified when the focus-window has changed, gets the PID of the respective window. Based on this PID we find the cgroup directory for that particular application. cgroups (control groups) is a Linux kernel feature that limits and isolates the resource usage of a collection of processes.

We then set an "inactive-since" timestamp which can be used to determine when the application was last active or if it is currently active(-1) as an extended attribute(xattr) on the cgroup directory. An extended attribute is a name:value pair associated permanently with a file or directory. Resource management daemons can then monitor the cgroup directories for these changes and make allocation decisions accordingly.

Window Tracker Extension Gitlab Repo: https://gitlab.gnome.org/nishalkulkarni/window-tracker-extension/

Current Status: Complete

Task 2 - Updating uresourced

uresourced is the place where most of the changes have taken place, from implementing the basic structure to working with experimental ideas. Hence I have given a more detailed module-wise breakdown for individual changes. However, you can check out the overall Merge request below.

uresourced Gitlab Merge Request: https://gitlab.freedesktop.org/benzea/uresourced/-/merge_requests/12

Current Status: Code review completed, pending merge.

Task 2A - App monitoring (RAppMonitor)

This change allows us to recursively monitors changes to the app.slice directory and sub-directories, I.e. the cgroups inside app.slice and emits a changed signal whenever the xattr on a directory have changed. Such a notification can also happen programatically by code monitoring other parts of the system, such as audio playback. It tracks all information using watch descriptors and app paths, stored in Hash Tables for convenience and fast access.

RAppMonitor code commit: https://gitlab.freedesktop.org/benzea/uresourced/-/merge_requests/12/diffs?commit_id=e695d8e2a89171000e2c8981fc83d7aa52e142d3

Task 2B - Resource allocation policy (RAppPolicy)

It is responsible for actually making the policy decisions and setting resources accordingly. Hence, allowing for a cleaner separation between tracking and resource allocation. It acts only when a changed signal is received from RAppMonitor. On receiving a changed signal it calculates the CPUWeight and makes a systemd DBus method call. Currently, only CPUWeight is adjusted for a particular cgroup and the allocation decision is based on 2 indicators

1. Timestamp - Active window (timestamp = -1) gets a weight of 1000 while non-active window gets default weight of 100.
2. Boosted - If boosted the application gets an additional weight of 500 irrespective of the applications current state (focussed or not)

RAppPolicy code commit: https://gitlab.freedesktop.org/benzea/uresourced/-/merge_requests/12/diffs?commit_id=e8cce224184af4a44bf6da6dc896dd7139f076cf

Task 2C - Audio monitoring using pipewire (RPwMonitor)

After having the basic structure in place I started working on using an additional indicator to boost applications. In this case pipewire is monitored for audio playback so that all applications using audio have their boosted flag set. This serves as a heuristic for detecting realtime applications so that they aren't as throttled as non-active applications.

It adds custom pipewire GSource to the main loop and listens to node events from pipewire-pulse API, after receiving state change from idle or suspended to running we set the boosted flag on RAppinfo for the associated cgroup and emit a changed signal.

RPwMonitor code commit: https://gitlab.freedesktop.org/benzea/uresourced/-/merge_requests/12/diffs?commit_id=f0ba15e0dd34b282ea7a7252bec1c97221b918c1

Task 2D - Boosting games using GameMode (RGameMonitor)

Another area where we can provide additional boost is games. We use a similar mechanism to boosting applications playing audio, taking advantage of a background utility called GameMode by Feral Interactive.

Every time a game is registered or unregistered we receive a signal from the dbus interface, we then make the app boosted depending on the respective signal.

RGameMonitor code commit: https://gitlab.freedesktop.org/benzea/uresourced/-/merge_requests/12/diffs?commit_id=395647b71d6f8ee381a93b0d0590d5ea32062a4e

Task 3 - Updates to mutter

Having an extension that does the job of setting xattr on cgroup directories is fine for experimentation but we want these changes to happen more subtly and that's where mutter comes into play. Like the PID associated with every MetaWindow we now have a cgroup associated with it. For now, it's a GFile identifying the cgroup directory for that particular MetaWindow and hence the application. Whenever there's a focus update detected the code takes care of updating the timestamp xattr on that application's cgroup directory.

mutter Merge Request: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1960

Current Status: Code review completed, pending merge.

Other Tasks and possible Future work

Talking about more places where we can utilize these cgroup features, we have currently put up a proposal to implement a way for large applications to manage multiple worker processes using an xdg-portal. This will be beneficial in providing better resource distribution and isolating bad actors.

xdg-desktop-portal Issue: https://github.com/flatpak/xdg-desktop-portal/issues/604

There are also other ideas for experimentation provided by my mentor like detecting battery draining applications using CPU Pressure information and collecting hints from .desktop file to make more policy decisions. However I could not address these during the stipulated time but thanks to the basic structure now in place, addressing them should be easy and is something I look forward to doing in the future.

Events - GUADEC

I gave my very first presentation at this years GUADEC Intern Lightning Talks and the whole event was an amazing experience for me! Right from getting to know what other interns have been working on, to the positive feedback from people in this community. I did attend a few other talks and BoFs and was truly fascinated by the work that has been going on.

GUADEC presentation: https://youtu.be/DjmL5YbcPEQ?t=6014

Slides used: https://github.com/nishalkulkarni/nishalkulkarni.com/blob/main/static/Nishal_GUADEC_Slides.pdf

Previous Blog Posts

If you want to know more, you can also checkout the following blog posts where I have documented my journey throughout GSoC 2021.

| Blog Title | Link | | ----------- | ----------- | | Part III - Merge Requests and GUADEC | https://nishalkulkarni.tumblr.com/post/659123986757730304/gsoc-2021-part-iii-merge-requests-and-guadec | | Part II - Tracking windows and monitoring files | https://nishalkulkarni.tumblr.com/post/654958606891040768/gsoc-2021-part-ii-tracking-windows-and | | Part I - Turning over a new leaf with GNOME | https://nishalkulkarni.tumblr.com/post/653170666946904064/turning-over-a-new-leaf-with-gnome |

Final thoughts

The entire GSoC experience was surreal, it has helped me learn a lot about the internals of how various parts of a desktop environment work, along with how I can utilise some kernel features. I feel part of a larger community in GNOME and feel more compelled to contribute to the various projects under it.

None of this would have been possible without the support from my mentors, there were a lot of areas that would have been difficult to understand if not for the right guidance from my mentors and I would like to thanks them for it.