You are not logged in.

#1 2025-08-30 15:09:37

marcoe
Member
Registered: 2025-08-30
Posts: 4

How to use the autogroup feature alongside systemd cgroups?

Hello,

I've been trying to make use of the kernel's autogroup feature to make browsing less choppy while compiling software. Upon further inspection and a lot of searching it appears that autogroups are unusable in their current form on systemd.

Autogroups are created and assigned at the `setsid(2) syscall` and "wanted" by the scheduler core only if the `kernel.sched_autogroup_enabled` is set to 1 and the current assigned `task_group` of a process is the `root_task_group` (most likely the top level cgroup as seen in `/sys/fs/cgroup` or a root cgroup of a namespace, e.g. in a container), see https://elixir.bootlin.com/linux/v6.16. … roup.h#L31

otherwise autogroup scheduling doesn't apply and the `task_group` is that of a cgroup as called by the scheduler. That said - and hoping I have understood the code correctly - the question remains how to meet these conditions under the systemd cgroup hierarchy? As every process spawned is attached to a non-root cgroup, be it `session-c1.scope`, `user@1000.service` or `app.slice`, meaning no process evaluated by the scheduler ends up having its `task_group` be the `root_task_group`.

I have tried cgroup delegation and the DisableControllers= configuration in hope it might affect it (somehow reassign `root_task_group`?) but it doesn't work like that.

The behavior I'm after is specifically automatic `task_group` creation via `setsid(2)`. I know I can use `systemd-run` to run a task in its own scope under different slices (with default CPUWeight=100) to simulate autogroup behavior, e.g.:

Terminal 1:
$ systemd-run --user --scope --slice=app.slice primesieve 1e12 -t 4  # I have a 4 core CPU

Terminal 2:
$ python3 -Sc 'while 1: pass'

This way I spawn a full package workload (primesieve) in the `app.slice` cgroup with default CPUWeight=100 and a single threaded workload in the default `user-1000.slice` with CPUWeight=100, they split 50/50 just like in the proper autogroup scenario i.e. `python` is running uninterrupted on one core and `primesieve` is sharing 3 cores among its 4 workers ~75% each. If I run `primesieve` without the inconvenient systemd-run incantation they share the default slice and the resulting 5 workers (both `python` and `primesieve`) get ~80% of CPU time each.

There are reports of people being annoyed by the autogroup feature due to it changing their expectation of how nice values behave in a `task_group`.

This user https://old.reddit.com/r/Fedora/comment … rk_around/ is describing the proper autogroup behavior under the non-unified cgroup hierarchy and how nice values applied to `task_groups` back then. Under the unified cgroup hierarchy the CPUWeight property has to be used and nice values are respected only within the newly created scope (cgroup, i.e. `task_group`).

Is it possible to somehow marry systemd with the autogroup feature by changing how it treats and attaches processes in the cgroup hierarchy (run everything in the root slice?) or do I have to explicitly spawn terminals in their own cgroup to achieve the desired behavior?

And, if the feature really doesn't work with modern systemd, maybe Arch should consider disabling the autogroup feature (CONFIG_SCHED_AUTOGROUP) in the default kernel config altogether (like openSUSE did: https://lists.opensuse.org/archives/lis … sort=date) to avoid causing further confusion (as it confused me) why it doesn't work as expected. I might even hazard a speculation and suggest that as time goes on the lack of proper `task_group` weight assignment on an overloaded system (N+const) workers / N cores will get more pronounced under bursty single threaded workloads alongside full package workloads (like code compile; the more cores, the slower fairness tends to 100% for each worker).

Offline

Board footer

Powered by FluxBB