[RFC] change systemd drivers to use sub-cgroups

[kolyshkin]

Currently, runc's systemd cgroup driver (both v1 and v2) set all the resources they can using systemd properties (and also sets Delegate=yes if possible, then sets all the resources using fs[2] driver. This seems wrong, as with Delegate=yes (see https://systemd.io/CGROUP_DELEGATION/) one is supposed to create and manage sub-cgroup(s) (as opposed to the cgroup of the systemd unit itself like it's currently done).

A possible fix is to create a systemd scope unit with minimal set of properties (Delegate=yes, DefaultDependencies=false, and those from org.systemd.property annotations (see https://github.com/opencontainers/runc/blob/master/docs/systemd-properties.md), then use fs[2] cgroup manager to create a sub-cgroup under it and set all the parameters.

This way, though, we won't see or be able to change any limits using systemd tooling.

[kolyshkin]

IOW, I think we violate this rule (from https://systemd.io/CGROUP_DELEGATION/):

🚫 Never write to any of the attributes of a cgroup systemd created for you. It’s systemd’s private property. You are welcome to manipulate the attributes of cgroups you created in your own delegated sub-tree, but the cgroup tree of systemd itself is out of limits for you. It’s fine to read from any attribute you like however. That’s totally OK and welcome.

[AkihiroSuda]

Related: #2448 (Support "run.oci.systemd.subgroup" annotation)

[AkihiroSuda]

SGTM. This behavior also corresponds to crun AFAIK.

[AkihiroSuda]

Added to rc93 milestone, but feel free to change.

[kolyshkin]

OK so we have discussed it with @mrunalp and @giuseppe and looks like we can proceed with the plan outlined in #2603.

The biggest concern about switching systemd drivers to create a sub-cgroup is that software that uses libcontainer (kubelet etc.) might break. We could do it as an option but I don't think there will be any benefit.

[AkihiroSuda]

So shall we close this?

[AkihiroSuda]

Ping @kolyshkin

[kolyshkin]

Yes, let's close this one (in favor of #2603).

Another thing why sub-cgroups are bad is the deeper the hierarchy is, the slower the kernel (this might eventually be fixed in the kernel, but in general it's a concern)/