All About the Linux Kernel: Cgroup's Redesign (Linux.com)

Right now cgroups is a traditional filesystem-based API which can be manipulated by pretty much anything. It supports usual delegation - just set the appropriate permissions on the filesystem and bind-mount it in a namespace.

Tejun Heo wants to replace it with a single daemon. No plans for delegation or access control are presented so far.

Myself and many others in the HPC industry are likely not pleased with this decision whatsoever. That being said, I do love systemd overall, just not this specific part of it.

> While the rework of the cgroups interface is coordinated with systemd people, cgroups won't be based on or depend on systemd.
Yeah, sure. Right now cgroups do whatever systemd people want, and damn the consequences.

> Cgroups are going to be more consistent across controllers and they are going to assume a single agent setting up and administrating a group (could be systemd, could be your custom management script, could be you from the shell).
Yeah, so there'll be no way for my user processes to setup their own cgroups.

And I actually DO use this. For example, I have a 'deeptime' utility to get the accurate runtime for a process tree which works by creating a cpuacct cgroup.

>There is a ton of cruft in the code that bends over backwards to support multiple users accessing the control and info knobs _at the same time_ but nobody is doing that anyway.
I understand, it's better if nobody (or only systemd, as a concession) has access to cgroups.

Also, somehow, /proc and /sys filesystems work without single entities controlling access to them.

> You can still delegate if you like, but delegate to a single entity.
How? And what if I don't WANT a single entity?

Don't get me wrong, I'm all for general cgroups interface cleanups. There are lots of missing or inconsistent features (there's no way to get notifications when cgroup becomes empty, for example). Multiple tree structure also complicates things - I totally understand that. IMO, merging blkio and memory controller totally makes sense.

But then we have freezer controller and cpuacct. I fail to see how merging them into the single controller would help. There are no places in the kernel where it's unclear if a resource should belong to cpuacct/freezer or to some other controller (like in the case of blkio and memcg). So why are they being merged?

For example, right now I'm using cpuacct to measure time spent in various kinds of processes (i.e. 10 cpu-seconds were spent in 'make', 20 cpu-seconds were spent in 'bash', etc). How am I going to do this with single cgroups, assuming that I need to gather statistics across several memcg system partitions?

Then there's freezer controller - we use it to atomically pause a graph of dependent processes (e.g. a Postgres database and its clients) in case of low-memory conditions. How are we going to do this with the single tree model?

So yes, I see that the development of cgroups follows the usual fouled-up course of previous cgroups development. Second-system syndrome in full force.