Skip to content

cgroups v2

Linux 5.1+ introduced cgroups v2, a unified control group system that replaces the legacy cgroups v1. This architecture simplifies resource management by merging all subsystems into a single hierarchical model, enabling fine-grained control over CPU, memory, I/O, and other resources. Unlike v1, which required separate hierarchies for each subsystem, cgroups v2 uses a single, unified hierarchy with shared controllers, making it more scalable and easier to manage.

Hierarchical Resource Management Model

In cgroups v2, resources are organized into a tree-like hierarchy of control groups (cgroups). Each node in the hierarchy represents a group of processes, and resource limits are applied recursively to all descendants. This hierarchical structure allows for nested resource allocation, where parent groups can define global constraints, and child groups inherit or override them.

For example: 

root
├── group1
│   ├── subgroup1
│   └── subgroup2
└── group2
- group1 might have a CPU limit of 50%, and subgroup1 could further restrict its children to 25%. - Processes in subgroup2 inherit the CPU limit from group1 unless explicitly overridden.

This model enables flexible resource partitioning, such as isolating a container's resources from the host while allowing nested containers to share or override limits.

Control Groups (Cgroups) in v2

Cgroups v2 introduces controllers, which are subsystems that manage specific resources. Each controller is a kernel module (e.g., cpu, memory, blkio) and can be attached to a hierarchy. Key controllers include:

  • CPU: Limits CPU shares and time.
  • Memory: Enforces memory usage caps.
  • Blkio: Controls disk I/O throughput.
  • Pids: Limits the number of processes.
  • Net_cls: Manages network traffic classification.

Controllers are mounted under /sys/fs/cgroup/, with each hierarchy containing a subdirectory for its controllers. For example: 

/sys/fs/cgroup/cpu/mygroup/
├── cpu.shares
├── cpu.cfs_period_us
└── cpu.cfs_quota_us

Example: Creating a cgroup with memory and CPU limits 

sudo cgcreate -g memory,cpu:/mygroup
sudo cgset -r memory.limit_in_bytes=1G mygroup
sudo cgset -r cpu.shares=512 mygroup

Namespace Isolation and Integration

While namespaces (e.g., PID, network, UTS) handle process isolation, cgroups v2 complements them by managing resource limits. For instance, a container might use namespaces to isolate its processes and cgroups to restrict its CPU and memory usage. This combination ensures both isolation and controlled resource allocation.

In cgroups v2, namespaces and cgroups are separate but interoperable. For example, a container might have its own cgroup hierarchy (managed via cgroup2), while its processes are isolated within a PID namespace. This separation allows for granular control over resource usage without affecting other system components.

Key Takeaways

  • Unified hierarchy: Cgroups v2 merges all subsystems into a single tree, simplifying resource management.
  • Hierarchical limits: Parent cgroups define global constraints, with child groups inheriting or overriding them.
  • Controllers: Subsystems like CPU, memory, and blkio are managed via controllers, enabling precise resource allocation.
  • Integration with namespaces: Cgroups v2 works alongside namespaces to provide both isolation and resource control.