Understanding Cgroups v2: Unified Hierarchy, Controllers, and Filesystem Interface

The previous article "浅谈Cgroups" introduced Cgroups v1, but its multiple hierarchies and controller management became complex as container technology evolved; Cgroups v2, introduced as a kernel feature in version 4.5.0, simplifies the hierarchy.

Background – Cgroups v1 allowed processes to belong to multiple hierarchies, but controllers could only be attached to a single hierarchy, leading to confusing implementations and limited cooperation between controllers such as memcg and blkio. Since kernel 3.16 the kernel moved toward a unified hierarchy to address these issues.

Cgroups v2 Changes

Cgroups v2 replaces the multi‑hierarchy model with a single unified hierarchy where all controllers are mounted together. Both v1 and v2 can coexist in the kernel, but the same controller cannot be mounted in both versions simultaneously.

The five major improvements in Cgroups v2 are:

All controllers are mounted under one unified hierarchy, eliminating the previous per‑hierarchy controller placement.

Processes can only be attached to the root ("/") or leaf nodes of the cgroup tree.

Available controllers are declared via cgroup.controllers and enabled controllers via cgroup.subtree_control.

Legacy files such as the v1 tasks file and cgroup.clone_children in the cpuset controller have been removed.

The notification mechanism for an empty cgroup has been improved through the read‑only cgroup.events file.

Unified Hierarchy

Mounting Cgroups v2 can be done with a single command, which automatically mounts all available controllers: mount -t cgroup2 none $MOUNT_POINT If a controller is already used by Cgroups v1, it must be unmounted from v1 before it can be used in v2. Systemd defaults to Cgroups v1; to switch to v2 at boot, add cgroup_no_v1=all (or a comma‑separated list of specific controllers) to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub.

Controllers

Cgroups v2 currently supports the following controllers:

io (since Linux 4.5)

memory (since Linux 4.5)

pids (since Linux 4.5)

perf_event (since Linux 4.11)

rdma (since Linux 4.11)

cpu (since Linux 4.15)

Subtree Control

Each cgroup contains two important files: cgroup.controllers – a read‑only list of all controllers available in that cgroup. cgroup.subtree_control – a writable list (subset of the above) that enables controllers for descendant cgroups. The file uses space‑separated entries prefixed with ‘+’ to enable or ‘‑’ to disable. Example: echo '+pids -memory' > x/y/cgroup.subtree_control "no internal processes" rule

Unlike v1, processes can only be attached to leaf cgroups; they cannot be bound to intermediate subgroups that have controllers enabled.

cgroup.events file

The old release_agent and notify_on_release mechanisms are removed. Instead, cgroup.events provides a simple key‑value notification where the key populated is 0 when the cgroup is empty and 1 when it contains processes.

cgroup.stat file

Each cgroup also contains a read‑only cgroup.stat file with two keys: nr_descendants – number of living sub‑cgroups. nr_dying_descendants – number of sub‑cgroups that have been destroyed but not yet reclaimed.

Descendant Cgroup Limits

Two files control the limits on the number and depth of descendant cgroups: cgroup.max.depth – maximum depth of the hierarchy (0 disables creation, max means unlimited). cgroup.max.descendants – maximum number of active sub‑cgroups (default max for unlimited).

For further reading, see the Linux man page for cgroups, the official cgroup2 documentation, and various technical articles linked at the end of the original post.