[arch-dev-public] Fwd: [systemd-devel] [HEADSUP] systemd cgroup changes

Thomas Bächler thomas at archlinux.org
Mon Jun 17 09:20:14 EDT 2013


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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-dev-public/attachments/20130617/f292bbcd/attachment.asc>


More information about the arch-dev-public mailing list