· Development

Is a load average of 4.0 high? What Linux load average counts and what 1, 5 and 15 minutes mean

Linux load average isn't CPU usage. It's a decaying average of runnable (R) and uninterruptible (D) tasks. How the kernel computes it, how to read it against CPU count, and how PSI differs.

DevelopmentOperating SystemsLinuxPerformance

The load average: 3.95, 2.10, 1.02 at the top of uptime or top isn’t a percentage. On Linux these three numbers average, over 1, 5 and 15 minutes, the count of tasks that are using or waiting for a CPU plus tasks in uninterruptible sleep (state D). The same 4.0 means different things depending on how many CPUs there are and what those tasks are waiting for.

No standard defines it

POSIX has no definition of load average. The Linux man page for the C function that reads it, getloadavg(), lists its standard as “BSD”, and the function first appeared in 4.3BSD-Reno. Both the Linux and FreeBSD getloadavg(3) pages describe it as the average number of processes in the run queue, but each kernel decides what counts as the run queue. This article covers the Linux kernel. I didn’t check how other systems count.

What Linux counts: R and D

proc_loadavg(5) says the first three fields of /proc/loadavg average the number of jobs in the run queue (state R) or waiting for disk I/O (state D). The comment in the kernel’s kernel/sched/loadavg.c is blunter: the global load average is an exponentially decaying average of nr_running + nr_uninterruptible.

Disk waits are the usual cause of state D, but the kernel goes by a state flag, not by the reason for waiting. A task that sleeps as TASK_UNINTERRUPTIBLE counts toward load. Tasks that also carry TASK_NOLOAD (the TASK_IDLE state), and frozen tasks, don’t count (block_task() in kernel/sched/core.c). That’s why ps(1) describes D as “uninterruptible sleep (usually I/O)”, with “usually”.

So load average can be high while the CPUs sit idle. If tasks pile up in state D waiting on a slow storage device, the number climbs even though CPU usage stays low. When the value is high, list tasks per thread with ps (for example ps -eLo pid,lwp,stat,wchan,comm) to see which processes the R and D tasks belong to and where in the kernel the D tasks are waiting. An instantaneous ps count won’t exactly reproduce the kernel’s load accounting, though, because the kernel samples and averages over time.

The 1-minute figure isn’t a plain 1-minute mean

Every LOAD_FREQ (5 seconds plus one tick) the kernel samples the current task count and blends it with the previous value:

new = previous × e + current count × (1 − e)

The factor e is stored in include/linux/sched/loadavg.h as fixed point, with 2048 meaning 1.0. EXP_1 for one minute is 1884, the 5-minute one is 2014 and the 15-minute one is 2037. They are e^(−5s/1min), e^(−5s/5min) and e^(−5s/15min), each multiplied by 2048.

Using these factors, if a system at 0 suddenly has four tasks that stay runnable, the 1-minute value after one minute (12 samples) is 4 × (1 − (1884/2048)^12) ≈ 2.5. That reflects only about 63% of the new state, and samples older than a minute still carry some weight. The 5- and 15-minute values move more slowly, so reading the three side by side hints at whether load is rising or falling. The kernel works in integers, so the decimals may differ slightly from this calculation.

Read it against the CPU count

uptime(1) states that load averages are not normalized for the number of CPUs. Its example: a load of 1 means a single-CPU system was busy all the time. On a four-CPU system, it means that about 75% of aggregate CPU capacity was idle, or three CPUs on average. A 4.0 made up mostly of R tasks leaves headroom on a server with 16 logical CPUs and means a queue on one with 2. Rules like “dangerous above the CPU count” are rules of thumb, and they don’t carry over directly to Linux figures that include D tasks.

/proc/loadavg holds two more fields. These are example values:

0.52 0.48 0.40 2/613 12345

In the fourth field, the number before the / is how many scheduling entities (processes and threads) are runnable right now and the number after it is how many exist. The fifth field is the PID most recently created. In the kernel source the number before the / comes from nr_running(), so it’s an instantaneous count, not an average, and it excludes state D.

PSI shows what tasks wait for

If the kernel is built with CONFIG_PSI, /proc/pressure/cpu, memory and io show, per resource, the share of time tasks were stalled, averaged over 10, 60 and 300 seconds. some is the share of time at least one task was stalled on that resource. full is the share of time all non-idle tasks were stalled at once. System-wide cpu full is undefined, and since 5.13 it is printed as zero for backward compatibility. Load average folds task counts into one number. PSI splits waiting time by resource.

For disk space that doesn’t come back because a file is still open, see unlink and open files.

Sources

  • Linux man-pages 6.19: proc_loadavg(5), getloadavg(3), proc_pid_stat(5)
  • procps-ng: uptime(1), ps(1)
  • Linux kernel source (checked at tag v7.2): kernel/sched/loadavg.c, include/linux/sched/loadavg.h, kernel/sched/core.c, include/linux/sched.h, fs/proc/loadavg.c
  • Linux kernel documentation: PSI - Pressure Stall Information
  • FreeBSD 15.1: getloadavg(3)

Back to the blog