Control resources with cgroup v2
Control groups (cgroups) let the Linux kernel limit, prioritise and account for
the resources a group of processes can use. In the version 2 unified hierarchy,
each resource type is handled by a controller — cpu, memory, io, pids,
cpuset, hugetlb, rdma and misc — exposed as plain files under
/sys/fs/cgroup. This tool lists every controller with its interface files
(knobs), showing which are read-only counters and which are writable limits.
How it works
A cgroup is a directory under /sys/fs/cgroup. Inside it you find the interface
files for the controllers its parent has delegated. Limits follow a consistent
naming scheme: <controller>.max is the hard ceiling, <controller>.current
reports live usage, and <controller>.stat gives a detailed breakdown. For a
controller to work in a child, the parent must list it in
cgroup.subtree_control (written with a + prefix). The cpu and io
controllers also support proportional sharing through a weight knob, while
cpuset pins tasks to specific CPUs and NUMA nodes. systemd creates and manages
most cgroups on a modern system, mapping unit options like MemoryMax= onto
memory.max.
Tips and notes
Treat memory.high as your first line of defence — it throttles before the hard
memory.max triggers an OOM kill. For I/O throttling, io.max takes per-device
entries keyed by MAJ:MIN, so look the device numbers up with lsblk first.
Pressure files (*.pressure) expose PSI stall metrics and are invaluable for
spotting CPU, memory or I/O contention before it becomes a hang. Always check
<controller>.controllers and cgroup.subtree_control if a knob you expect is
missing — the controller may simply not be delegated to that cgroup.