[arch-dev-public] Fwd: [systemd-devel] [HEADSUP] systemd cgroup changes
FYI, for those not subscribed to systemd-devel. Doesn't seem like this will affect too much, unless you've been heavily tweaking your services. ----- Forwarded message from Lennart Poettering <lennart@poettering.net> -----
Date: Mon, 17 Jun 2013 14:49:55 +0200 From: Lennart Poettering <lennart@poettering.net> To: systemd Mailing List <systemd-devel@lists.freedesktop.org> Cc: Tejun Heo <tj@kernel.org> Subject: [systemd-devel] [HEADSUP] systemd cgroup changes
Heya,
in the past weeks we have been sitting down with the cgroup maintainer in the kernel, Tejun Heo, at a number of conferences. During these discussions it became very clear to us that the way systemd currently exposes cgroups exposes too much of the guts of it, and is incompatible with how the kernel cgroup subsystem will be cleaned up in the near-term feature.
Hence I'd like to let everybody in the systemd community know that the cgroup settings, commands and APIs in systemd will change soon. Please be aware of this when you make use of advanced cgroup functionality.
- The functionality to define orthogonal cgroup trees for the various controllers will be removed. In fact we'll likely remove the entire API for setting abritrary per-controller paths for each unit. Instead we will introduce a new concept of "Slices" which will allow you to partition system resources in a tree and move units, users, and machines to arbitrary places in it. There will only be a single cgroup tree, but the various controllers may be enabled/disabled separately for each group, so that individual controllers might only see a subtree of the full tree, but not orthogonal trees anymore. The ConrolGroup= unit setting will go away, and be replaced by Slice= plus EnableControllers= or so.
- ControlGroupPersistent= will likely go away, systemd will be the only component of the OS that sets up the cgroup tree.
- ControlGroupAttribute= will most likely go away entirely. Instead we will introduce more high level controls like the existing CPUShares=, MemoryLimit= and so on. (BTW, if there's a specific attribute we currently don't cover but which you really need let us know and we will see if we can add a high-level control for it.)
- CPUShares=, MemoryLimit= and so on will continue to exist as before.
- "systemctl set-cgroup" will go away, and be replaced by systemctl "set-slice" or something similar.
- "systemctl set-cgroup-attr" will go away, and be replaced by "systemctl set-attr" or so, which only can set the high level attributes.
- The (currently undocumented) bus APIs for cgroup controls will be replaced.
Sorry for this disruption. Thankfully we have not documented these APIs yet and we haven't made the funcionality too widely known. We hate to make incompatible changes like this, but in this case it's probably better to clean this up early when it is not often used instead of late when everybody already uses this.
This will remove a few bits of functionality but all in all give you a lot more back. For example, the "slice" functionality will provide you with a powerful and naturally built-in way to partition your resources in arbitrary ways, and can be used to not only assign resource limits to systemd units but also login users and machines.
We haven't hashed out all the details yet, but expect this to land very soon in git.
Thanks,
Lennart
-- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
----- End forwarded message -----
Am 17.06.2013 15:03, schrieb Dave Reisner:
FYI, for those not subscribed to systemd-devel. Doesn't seem like this will affect too much, unless you've been heavily tweaking your services.
It will affect me a lot. I use custom memory and cpu/cpuacct cgroups outside of systemd, which brings me to my question ...
- The functionality to define orthogonal cgroup trees for the various controllers will be removed. In fact we'll likely remove the entire API for setting abritrary per-controller paths for each unit. Instead we will introduce a new concept of "Slices" which will allow you to partition system resources in a tree and move units, users, and machines to arbitrary places in it. There will only be a single cgroup tree, but the various controllers may be enabled/disabled separately for each group, so that individual controllers might only see a subtree of the full tree, but not orthogonal trees anymore. The ConrolGroup= unit setting will go away, and be replaced by Slice= plus EnableControllers= or so.
Is this only a systemd change, a kernel change or both? Does this mean I will no longer be able to move processes in custom cgroups and instead have to enable controllers in a unified tree? I'm not quite sure I understand this change.
- ControlGroupPersistent= will likely go away, systemd will be the only component of the OS that sets up the cgroup tree.
I don't use ControlGroupPersistent, but I like messing with cgroups manually. These explanations are a bit unclear to me. I guess we'll have to wait and see what gets implemented.
participants (2)
-
Dave Reisner
-
Thomas Bächler