Cgroup

Cgroups, short for control groups, are a Linux kernel feature that limits, accounts for, and isolates the resource usage of processes. They enable administrators to assign processes to named control groups and enforce limits on CPU time, memory, disk I/O, and other resources. Cgroups were designed to support multi-tenant systems and containerization, providing predictable resource availability and isolation.

Architecture and versions: A cgroup hierarchy forms a tree. Each node represents a control group; processes join a group by membership and inherit the limits of their ancestors. Subsystems, called controllers, implement specific resources, such as cpu, cpuacct, memory, blkio, devices, pids. In cgroups version 1, controllers can be mounted in separate hierarchies, enabling independent resource control. Cgroups version 2 introduces a unified hierarchy in which multiple controllers are exposed under a single tree, simplifying management and eliminating some cross-controller interactions.

Management: Administrators create cgroups, move processes into them, and configure limits by writing to files in the cgroup filesystem (for example, memory.limit_in_bytes, cpu.cfs_quota_us, and pids.max). System services and container runtimes commonly rely on cgroups; systemd uses them to govern services and scopes, while container engines such as Docker and Kubernetes assign containers to cgroups to cap resource usage.

Impact and limitations: While cgroups provide effective resource isolation and accounting, they are not permission boundaries or security boundaries on their own. Correct configuration of controllers and limits is essential, and some workloads require careful tuning to avoid deadlock or contention. The development of cgroups continues with ongoing kernel and tooling improvements, including tooling for unified cgroup v2 management and better integration with init systems and orchestration platforms.