The Linux Control Groups (cgroups) is a mechanism provided by the Linux kernel to limit, control, and isolate the resources (such as CPU, memory, disk I/O, etc.) of a group of processes. Cgroup v1 and v2 are two major versions that have significant differences in design and functionality.
1. Architecture
- cgroup v1:
- Uses a hierarchical controller design, where each subsystem (such as CPU, memory, I/O, etc.) has its own independent hierarchy.
- Each hierarchy can be mounted independently, allowing processes to belong to multiple hierarchies, which complicates configuration.
- Different controllers may have different hierarchy affiliations for the same process, leading to decentralized management.
- cgroup v2:
- Adopts a unified hierarchy design, where all controllers share a single hierarchy structure.
- All resource control is done within a single hierarchy, simplifying management and configuration.
- The unified hierarchy avoids the inconsistencies between controllers found in v1.
2. Interface and Usability
- cgroup v1:
- Each controller has its own filesystem mount point (e.g.,
<span>/sys/fs/cgroup/cpu</span>,<span>/sys/fs/cgroup/memory</span>). - Configuration is decentralized, requiring manual management of multiple mount points, increasing complexity.
- Some controller functionalities overlap or are inconsistent (e.g., CPU and CPUSET).
- cgroup v2:
- All controllers are managed through a single mount point (e.g.,
<span>/sys/fs/cgroup</span>). - Provides a unified interface file (e.g.,
<span>cgroup.controllers</span>,<span>cgroup.subtree_control</span>), making configuration easier. - Improves user experience and reduces configuration errors.
3. Resource Control Granularity
- cgroup v1:
- Controller functionalities are more decentralized, and control over certain resources (e.g., memory) is not fine-grained enough.
- Lacks support for certain advanced resources (e.g., I/O latency, pressure metrics).
- cgroup v2:
- Memory: Supports more granular memory limits (e.g., high/low watermarks, OOM control).
- I/O: Supports weight-based I/O scheduling (
<span>io.weight</span>) and more precise I/O limits. - CPU: Supports more flexible CPU allocation (e.g.,
<span>cpu.weight</span>and<span>cpu.max</span>). - Provides finer resource control, such as:
- Introducing pressure metrics (pressure stall information) for monitoring resource bottlenecks.
4. Process Management
- cgroup v1:
- Processes can belong to different controllers within the same hierarchy, leading to complexity.
- Does not support strict hierarchical constraints, which may lead to incorrect process allocation.
- cgroup v2:
- Forces processes to belong to only one cgroup within a single hierarchy, simplifying process management.
- Introduces the domain controller concept to ensure consistency in resource allocation.
- Supports thread-level control, allowing threads to be allocated to sub-cgroups (not supported in v1).
5. Compatibility and Transition
- cgroup v1:
- Long-standing, widely used in older systems and tools (e.g., early versions of Docker, Kubernetes).
- Good compatibility, but functionality is gradually being replaced by v2.
- cgroup v2:
- Newer version, some older tools may not support it (e.g., early Docker requires additional configuration).
- Modern Linux distributions (e.g., Ubuntu 21.10+, Fedora 31+) use v2 by default.
- Provides a backward compatibility mode (
<span>systemd</span>supports mixed mode for v1/v2).
6. Functional Features
- cgroup v1:
- Basic functionality, some controllers (e.g.,
<span>blkio</span>) have limited capabilities. - Does not support a unified resource allocation strategy, making optimization difficult in certain scenarios.
- cgroup v2:
- Delegation: Allows user-space programs to manage sub-cgroups.
- Unified Resource Allocation: All controllers share a consistent view of resources.
- Freeze: Supports pausing/resuming processes of an entire cgroup.
- New features, such as:
- More suitable for containerized environments (e.g., modern Docker, Kubernetes).
7. Performance and Overhead
- cgroup v1:
- Multi-level design may lead to performance overhead, especially in complex configurations.
- Interactions between controllers may incur additional overhead.
- cgroup v2:
- The unified hierarchy reduces kernel overhead, resulting in better performance.
- More efficient resource management and monitoring mechanisms.
Conclusion
| Feature | cgroup v1 | cgroup v2 |
|---|---|---|
| Hierarchy Structure | Decentralized multi-level | Single unified hierarchy |
| Interface | Decentralized mount points, complex | Single mount point, unified interface |
| Resource Control | Coarse, limited functionality | Finer, supports advanced features like pressure metrics |
| Process Management | Cross-hierarchy, complex | Single hierarchy, thread-level control |
| Compatibility | Widely supported in older systems | New systems by default, some old tools need adaptation |
| Performance | Higher overhead | More efficient, lower overhead |
Recommendations
- If you are deploying modern applications (such as containerized environments) on new systems, it is recommended to prioritize using cgroup v2 for better performance and functionality.
- If you need compatibility with older systems or tools, check if you need to use v1, or configure mixed mode through
<span>systemd</span>. - Check if your system has v2 enabled by default:
<span>cat /sys/fs/cgroup/cgroup.controllers</span>(if there is output, it is usually v2).