Linux cgroups v2: Unified Hierarchy and Resource Isolation

Control groups (cgroups) form the foundational isolation primitive for modern Linux process supervision, container runtimes, and systemd slices. The transition from legacy cgroups v1 to the unified cgroups v2 architecture resolved long-standing architectural flaws, including cross-controller synchronization deadlocks and uncoordinated memory-plus-swap accounting. Under cgroups v2, a process belongs to exactly one hierarchical group governed by a single unified tree mounted at /sys/fs/cgroup.

In multi-tenant cloud hosting and container environments, cgroups v2 allows operators to set absolute limits and proportional weights across CPU cycles, memory allocations, swap consumption, and block I/O operations. This prevents noisy-neighbor degradation without requiring full virtualization boundaries.

Expand

Creating and Configuring a Manual cgroup v2 Tree

Under cgroups v2, controllers must be explicitly enabled at each level of the tree via cgroup.subtree_control before child groups can regulate those resources. The rule of no-internal-processes enforces that processes may only reside in leaf nodes, eliminating ambiguity over how unassigned tasks consume parent quotas.

# Verify that unified cgroup v2 is mounted
mount -t cgroup2

# Enable memory, cpu, and io controllers on root
sudo sh -c 'echo "+cpu +memory +io" > /sys/fs/cgroup/cgroup.subtree_control'

# Create dedicated workload group
sudo mkdir -p /sys/fs/cgroup/workloads/tenant1

# Set 1GB memory limit and throttle swap
sudo sh -c 'echo "1073741824" > /sys/fs/cgroup/workloads/tenant1/memory.max'
sudo sh -c 'echo "268435456" > /sys/fs/cgroup/workloads/tenant1/memory.swap.max'

# Assign CPU quota: 2 cores maximum (200000us per 100000us period)
sudo sh -c 'echo "200000 100000" > /sys/fs/cgroup/workloads/tenant1/cpu.max'

Processes moved into /sys/fs/cgroup/workloads/tenant1/cgroup.procs are immediately constrained by these ceilings. If the group attempts to allocate beyond 1GB, the kernel initiates synchronous reclaim; if memory cannot be reclaimed, only processes within that specific group are targeted by the OOM-killer.

Production Integration with systemd Slices

While raw sysfs manipulation demonstrates the underlying kernel mechanism, production Linux distributions manage cgroups through systemd slice units. This ensures that limits survive service restarts and integrate cleanly with dynamic logging.

# /etc/systemd/system/customer-api.service
[Unit]
Description=Customer API Microservice
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/api-server
Slice=workloads.slice
MemoryHigh=768M
MemoryMax=1G
CPUWeight=100
IOWeight=100
TasksMax=1024

[Install]
WantedBy=multi-user.target

In this configuration, MemoryHigh acts as a throttled warning watermark: once crossed, the kernel aggressively reclaims page cache without killing the daemon. Only if utilization breaches MemoryMax will the service face memory termination.

System Subsystems Overview

Inspect this deep-dive guide to understand how the Linux kernel schedules and limits operating system resources:

Verifying cgroup Status

Inspect active controller consumption across your slices using standard system utilities:

# Display live resource consumption by systemd cgroup slices
systemd-cgtop -m

# Inspect the full process tree mapped into cgroups
systemd-cgls

Enforcing strict cgroups v2 boundaries ensures that unconstrained background jobs cannot starve critical edge web servers or database processes.

Deploy isolated multi-tenant services on low-latency cloud VPS instances in Lucknow at netbayhosts.in.