Most desktop users never really interact with Linux’s cgroups (control groups), and less experienced users may not even be aware of their existence. However, cgroups can be leveraged for useful things as a desktop user. For example, cgroups offer the ability to freeze or unfreeze, or limit the CPU time or memory usage, of groups of tasks.
With systemd, all unique systemd services, as well as anything that is activated via D-Bus, such as when you launch an app from the application menu (but not running it from the command line) are put into their own cgroups as a tree structure that can be accessed from /sys/fs/cgroup. I’m not going to give a whole intro to it here, there are plenty of tutorials if you’re curious.
Say I have a single-player game running that is relatively heavy on idle CPU usage. I don’t want to close it, but I’d like to have as much CPU time available at the moment, for, say, code compilation. I can leverage the ability to freeze cgroups so that the game consumes zero CPU time. When I want to go back to playing it, I can unfreeze the cgroup and the game continues to play like nothing ever happened (note that you may drop a connection to a server if it’s frozen for too long). You can do this easily enough from the commandline, but that’s not convenient nor discoverable. So, I propose that Plasma System Monitor should get this functionality, as well as making it accessible via a desktop/panel widget.
There are a couple caveats to implementing this. Freezing a cgroup triggers the “Not Responding” dialog. This would be easy enough to fix by checking if the process’ cgroup is frozen before popping it up, or even having a different way of darkening the window, maybe adding “Suspended” to the window title (because adding “Frozen” may imply that the program is frozen in the usual sense). This happens in GNOME too, fwiw.
Another caveat is that if you accidentally freeze the wrong thing, you won’t be able to interact with what you need in order to unfreeze it unless you switch to another VT and log in to another session. So we’d need protections against doing so. Also, we must warn the user about things like freezing processes that have active TCP/UDP connections dropping them due to timing out. For memory usage limits, we should note that this is really only to prevent a misbehaving process from taking down the rest of the system, and that if you set a limit too low, the process will start swapping instead and may OOM. There’s probably more safeguards that I haven’t thought of as well.
The last caveat is that not everyone may be using systemd (while some other init systems like OpenRC do offer cgroups integration, it’s only for system services. Without a proper user service/session manager, more is not possible. Chimera Linux with DInit/turnstiled could theoretically do it though), not everyone may have a kernel with all the cgroup controllers enabled, and not everyone has the cgroup filesystem mounted the same way (v1, v2, hybrid). So we have to be careful about how these things are enumerated and displayed or not to the user, and not crash.
To conclude, Is this something that people think would be useful/would like to see implemented?
