Per-Container Pressure Metrics
One of the most powerful features of PSI is its deep integration into cgroups v2 (the Linux control group mechanism used to isolate and resource-limit containers). This means you don't just get one global pressure number for the entire host — you get per-cgroup pressure metrics that reflect the "pain" felt by each individual workload.
Every cgroup v2 directory exposes its own cpu.pressure, memory.pressure, and io.pressure files alongside its resource limit files — for a Docker container, nested under a path like /sys/fs/cgroup/system.slice/docker-<id>.scope/.
Why this matters for Kubernetes and container platforms:
Consider a node running three containers. The host-level /proc/pressure/cpu shows some avg10=40%. That's alarming — but which container is responsible? With cgroup PSI, you can check each container's cpu.pressure individually. You might find Container A (a batch job) has 85% CPU pressure, while Containers B and C (your production services) have near-zero pressure. The batch job is hurting itself, but the production workloads are fine.
This granularity enables PSI-based resource management: Kubernetes and systemd can use per-cgroup PSI thresholds to make scheduling decisions, trigger throttling, or evict pods before they impact neighbors. The Kubernetes MemoryPressure node condition and the Linux kernel's PSI_POLL mechanism (which allows processes to register for notifications when pressure crosses a threshold) are both built on this foundation.
Enabling PSI in cgroup v2: PSI is enabled by default on most modern distributions (Ubuntu 20.04+, RHEL 9+, Debian 11+) when cgroup v2 is active. You can confirm it's available by checking that the pressure files exist under /sys/fs/cgroup/.