What the unified hierarchy means

Linux cgroup v2 is a kernel interface for hierarchical resource accounting and control over groups of processes. Unlike v1, it exposes a unified hierarchy rather than separate hierarchies for each controller. That does not mean every controller is enabled or available on every host. Inspect cgroup.controllers, each parent’s cgroup.subtree_control, mount options, and kernel configuration. Control files and behavior for CPU, memory, and I/O depend on the running kernel and the relevant controller.

Ownership and delegation under systemd

The systemd project’s control-group interface guide explains the single-writer model: each cgroup is managed by one userspace component. On a system where systemd is PID 1, direct edits to arbitrary cgroup files can conflict with the manager; use unit resource properties for systemd-owned groups. A service that must create its own child groups needs explicit delegation, commonly configured with Delegate=yes, and should manage only its delegated subtree. Hosts using another init system or runtime require that manager’s ownership and permission rules instead.

Controller files express different policies

Files such as cpu.max, memory.max, and io.max control different resources; setting a limit does not itself guarantee application performance or fairness. I/O behavior can depend on block-device, filesystem, and kernel support. Domain controllers in v2 impose constraints when enabling controllers for child groups, including the no-internal-process constraint in relevant domain configurations. It should not be generalized into a ban on all process-bearing groups: threaded subtree modes have different rules.

PSI and OOM policy are separate pieces

Pressure Stall Information lets the kernel report time tasks are delayed by CPU, memory, or I/O pressure and can be exposed at cgroup level. The some and full averages and cumulative totals have distinct meanings; they are not a single utilization percentage. File availability and configuration depend on the kernel. systemd-oomd can use PSI signals, but that does not imply every distribution or Kubernetes node terminates containers in the same way. Distinguish userspace oomd policy from kernel OOM handling and kubelet’s node-pressure eviction behavior.

Expert operator perspective on the transition

Red Hat container practitioner Dan Walsh recounts that compatibility across container tools and distributions delayed enabling cgroup v2 by default, and that Fedora plus Podman, CRI-O, and crun work helped move the ecosystem forward. This is a historical operator account, not a current compatibility matrix for every distribution. Before relying on limits, verify the host’s actual hierarchy, controller files, kernel and systemd versions, runtime support, and observed per-container enforcement; test differences from any v1 setup.

References