Pressure stall information, usually abbreviated PSI, is a Linux kernel feature that measures how much time runnable work is delayed because a resource is in short supply. Instead of reporting how busy the CPU, memory or storage is, it reports the share of wall-clock time during which tasks were stalled waiting for that resource, which makes it a direct measure of lost productivity.
PSI was merged in Linux 4.20 in 2018 and is exposed through files in /proc/pressure and, for cgroup v2, in each control group. In Linux monitoring it fills a gap left by utilization metrics and load average, and it is the signal behind modern user-space out-of-memory handlers.
How pressure stall information is measured
The kernel tracks, for every CPU, whether tasks are runnable but waiting for a resource. A task stalls on CPU when it is ready to run but another task holds the processor, on memory when it waits for page reclaim, refaults of evicted pages or swap-in, and on I/O when it waits for block device requests to complete.
PSI distinguishes two levels of stall. The some line reports the time during which at least one task was stalled, which indicates added latency. The full line reports the time during which all non-idle tasks were stalled simultaneously, meaning no productive work happened at all on that resource.
Each file reports running averages and a cumulative counter, as described below.
| Field | Meaning | Unit |
|---|---|---|
| avg10 | Stall share over the last 10 seconds | Percent of wall time |
| avg60 | Stall share over the last 60 seconds | Percent of wall time |
| avg300 | Stall share over the last 5 minutes | Percent of wall time |
| total | Cumulative stall time since boot | Microseconds |
The averages are exponentially weighted moving averages, similar in spirit to load average but expressed as a percentage. The total counter is the better input for monitoring systems, because rates can be computed over any interval without depending on the kernel smoothing windows.
PSI files and resources
System-wide pressure lives in /proc/pressure/cpu, /proc/pressure/memory and /proc/pressure/io. With cgroup v2, every control group exposes the same data in cpu.pressure, memory.pressure and io.pressure, so the pressure of a single container or systemd service can be measured separately.
| Resource | What causes a stall | Interpretation of full |
|---|---|---|
| CPU | Runnable tasks waiting for a processor | Meaningful mainly at cgroup level |
| Memory | Reclaim, refaults, swap-in, compaction | Workload thrashing, near OOM |
| I/O | Waiting for block device completion | Storage is the bottleneck |
| IRQ | Time lost to interrupt handling | Available in newer kernels with IRQ accounting |
PSI must be enabled in the kernel build with CONFIG_PSI. Some distributions compile it but disable it by default, in which case the boot parameter psi=1 activates it. The accounting cost is small, typically well under one percent of CPU, which is why it is enabled on most current systems.
PSI compared with traditional monitoring metrics
Classic Linux metrics describe how much of a resource is used, not whether the shortage hurts workloads. A server at 95% CPU utilization may run perfectly if no task waits, while a host with free memory can still thrash if its working set does not fit in page cache.
| Metric | Source or tool | What it shows | Main weakness |
|---|---|---|---|
| CPU utilization | top, htop, sar | Busy versus idle time | Does not show waiting tasks |
| Load average | uptime, /proc/loadavg | Runnable plus uninterruptible tasks | Mixes CPU and I/O, not normalized |
| Free memory | free, vmstat | Unused and available pages | Says nothing about thrashing |
| I/O wait | iostat, vmstat | Idle CPU time with pending I/O | Misleading on multi-core systems |
| PSI | /proc/pressure | Time lost to resource shortage | Does not name the culprit process |
PSI therefore works best as a health signal that triggers investigation, followed by tools such as iotop, vmstat or per-process statistics to identify the cause.
Using PSI thresholds and triggers
Applications can register PSI triggers instead of polling the averages. A process writes a line such as some 150000 1000000 into a pressure file, meaning 150 ms of stall within any 1-second window, and then waits for an event with poll. The window must lie between 500 ms and 10 seconds, and unprivileged users face stricter limits in newer kernels.
Useful thresholds depend on the workload, so the values below are starting points to be tuned against latency objectives.
| Signal | Starting threshold | Typical action |
|---|---|---|
| memory some avg10 | Above about 10% | Investigate, consider more memory |
| memory full avg10 | Above about 5-20% | Shed load or kill low-priority work |
| io some avg60 | Above about 20% | Check storage latency and noisy neighbors |
| cpu some avg60 in a cgroup | Above about 25% | Raise CPU quota or scale out |
systemd-oomd and Android’s low-memory killer use memory pressure to act before the kernel OOM killer, which only reacts when allocation fails and often after a long period of unresponsiveness. Container platforms and autoscalers increasingly read PSI as an input as well.
Pitfalls when interpreting PSI
- System-wide CPU full is not a meaningful number on a whole machine and is reported as zero there; use cgroup values instead.
- Short spikes in avg10 are normal during deployments or cache warm-up; alert on sustained values.
- CPU throttling by quotas in cgroups shows up as pressure even when the host has idle cores.
- Comparing hosts with different core counts or disks requires care, because the percentage is relative to available capacity.
- Older kernels before 4.20 lack PSI entirely, so fleet-wide dashboards must handle missing files gracefully.
Stripped to the essentials
Pressure stall information tells you how much time programs spend waiting because the computer is short of something. That something can be processor time, memory or disk speed.
Think of a supermarket. Counting how many tills are open says little. Measuring how long customers stand in the queue tells you whether the shop is really struggling. PSI is that queue time for a Linux system.
Where it is applied
A platform team runs a Kubernetes node pool for internal web services. Memory graphs show 20% free memory, yet some pods respond slowly every afternoon. The team adds memory.pressure from each pod cgroup to its dashboards and sees memory some avg10 rising above 30% for one analytics pod during its daily batch job.
The pod has a memory limit just below its working set, so it constantly evicts and refaults its own page cache. Raising the limit by 1 GiB brings pressure below 2% and the latency problem disappears. The team then adds an alert on sustained memory pressure, which catches similar limits before users notice.