A Linux host can report modest CPU utilization while runnable work is delayed, or ample memory capacity while tasks repeatedly stall in reclaim. Utilization counters describe resource activity; pressure stall information records time in which work cannot make progress because a resource is contended.
PSI exposes that lost execution opportunity through CPU, memory, and I/O pressure files. Its central distinction is between a stall affecting at least one task and a stall that leaves every non-idle task unable to make progress.
Pressure measures blocked progress rather than capacity
System-wide PSI data appears under /proc/pressure/:
/proc/pressure/cpu
/proc/pressure/memory
/proc/pressure/ioMemory and I/O commonly expose two lines:
some avg10=1.25 avg60=0.80 avg300=0.42 total=9812456
full avg10=0.18 avg60=0.09 avg300=0.04 total=712004some accumulates intervals in which at least one task is stalled on the resource. Other tasks may still execute useful work during those intervals.
full is the stricter state: all non-idle tasks are stalled simultaneously. The machine may still execute kernel activity, but the tracked workload has no task making useful forward progress. Extended full pressure is therefore a stronger saturation signal than a comparable amount of partial pressure.
At the system level, CPU pressure has a special boundary. CPU full is not a meaningful whole-system metric because a runnable task waiting for CPU implies another task can be executing on that CPU. Linux reports the system-level CPU full value as zero for compatibility.
The averages represent stall-time ratios
The avg10, avg60, and avg300 fields are percentages derived from recent stall activity over approximately 10-second, 60-second, and 300-second horizons. They are not counts of blocked tasks and they are not resource-utilization percentages.
A memory some avg10=20.00 value means partial memory stalls occupied a substantial fraction of recent wall-clock time. It does not mean 20 percent of RAM is unavailable, 20 percent of tasks are blocked, or reclaim consumed 20 percent of CPU time.
The total field is cumulative stall time in microseconds. Sampling the delta between two observations gives an absolute measure that can expose a short pressure burst even when longer moving averages barely change.
This difference matters for incident data. A five-second reclaim episode can produce a sharp total increase while the 300-second average remains visually small.
Partial and total stalls separate degraded concurrency from collapse
Consider a service with eight worker tasks. During storage contention, two workers may wait for synchronous I/O while six continue processing requests. I/O some grows because part of the workload is stalled, but full does not grow while another non-idle task remains productive.
If all eight workers eventually wait on storage at the same time, I/O full starts accumulating. The resource bottleneck has moved from reduced parallelism to a period with no productive worker.
The same distinction applies to memory pressure. Direct reclaim or related memory stalls can affect a subset of tasks first. As pressure intensifies, simultaneous stalls can consume all available application concurrency.
A large gap between some and full can therefore describe a workload that is losing throughput while retaining forward progress. Values that rise together indicate intervals where concurrency no longer hides the resource delay.
PSI complements utilization and queue metrics
High utilization does not necessarily imply high pressure. A CPU can remain nearly fully occupied while runnable tasks receive acceptable service. Conversely, CPU pressure can rise when runnable work spends material time waiting for execution even though a coarse utilization sample does not reveal the scheduling delay clearly.
I/O device utilization has a similar separation. A storage device may be busy without delaying latency-insensitive asynchronous work. PSI grows only when tracked tasks enter qualifying stall states, making it closer to workload impact than a raw device-busy counter.
Memory capacity is even less interchangeable with pressure. Free-memory values can be low on a healthy cache-heavy host, while a different host with more nominally available memory can incur reclaim or refault activity that stalls tasks.
PSI does not replace scheduler, block-layer, virtual-memory, or application latency telemetry. It supplies a common time-based signal that indicates whether resource contention is translating into lost progress.
Cgroup pressure narrows the affected workload
On cgroup v2 systems with PSI support, resource pressure is also exposed inside cgroups:
cpu.pressure
memory.pressure
io.pressureThis scope changes the interpretation. System-wide pressure answers whether tasks across the host are losing progress. Cgroup pressure isolates stalls attributed to tasks in a particular control group.
A container can therefore experience material memory or I/O pressure without producing a dramatic host-wide average. The reverse is also possible: host pressure can be driven by neighboring workloads while a particular cgroup remains relatively unaffected.
This separation is useful in shared systems because resource scarcity and workload impact do not always have the same administrative boundary.
Threshold triggers convert accumulated stalls into events
PSI files also support threshold monitors. A process can register a some or full threshold expressed as accumulated stall microseconds within a tracking window, then wait for readiness through polling interfaces.
A threshold such as:
some 150000 1000000represents 150 milliseconds of partial stall time within a one-second window. It is based on accumulated pressure inside that interval rather than an instantaneous utilization threshold.
The event model makes short bursts observable without continuously sampling moving averages. Each trigger is associated with its own open PSI file descriptor, and closing that descriptor removes the trigger.
Kernel limits on tracking windows and notification frequency bound the monitoring overhead. The mechanism is intended for pressure events, not high-frequency tracing of every individual task stall.
Pressure is an impact signal, not a root-cause label
A rising PSI value identifies lost progress associated with CPU, memory, or I/O contention. It does not identify the specific process, device, allocation path, lock interaction, or request pattern that created the contention.
High memory pressure can accompany direct reclaim, refault-heavy working sets, swap activity, or other memory-management costs. High I/O pressure can reflect storage latency, queueing, filesystem behavior, or synchronous access patterns. CPU pressure indicates runnable work waiting for execution but does not assign the scheduling competition to a single source.
That boundary keeps PSI useful as a compact saturation signal. It quantifies the time impact of resource scarcity while leaving causal attribution to more specific scheduler, memory, block, cgroup, tracing, and application telemetry.