UNIX Load Average Part 1: How It Works

In this online article Dr. Gunther digs down into the UNIX kernel to find out how load averages (the “LA Triplets”) are calculated and how appropriate they are as capacity planning metrics. With apologies to Jules Verne and his novel “20,000 Leagues Under the Sea,” I might equally have entitled this piece, “20,000 Lines Under the Shell.”

Have you ever wondered how those three little numbers that appear in the UNIX® load average (LA) report are calculated?

This TeamQuest paper explains how and how the load average (LA) can be reorganized to do better capacity planning. But first, try testing your knowledge with the “LA Triplets” Quiz.

In this two part-series I want to explore the use of averages in performance analysis and capacity planning. There are many manifestations of averages e.g., arithmetic average (the usual one), moving average (often used in financial planning), geometric average (used in the SPEC CPU benchmarks), harmonic average (not used enough), to name a few.

More importantly, we will be looking at averages over time or time-dependent averages. A particular example of such a time-dependent average is the load average metric that appears in certain UNIX commands. In Part 1 I shall look at what the load average is and how it gets calculated. In Part 2 I’ll compare it with other averaging techniques as they apply in capacity planning and performance analysis. This article does not assume you are a familiar with UNIX commands, so I will begin by reviewing those commands which display the load average metric. By Section 4, however, I’ll be submerging into the UNIX kernel code that does all the work.

1. UNIX Commands

Actually, load average is not a UNIX command in the conventional sense. Rather it’s an embedded metric that appears in the output of other UNIX commands like uptime and procinfo. These commands are commonly used by UNIX sysadmin’s to observe system resource consumption.

Let’s look at some of them in more detail.

1.1 Classic Output



The uptime shell command produces the following output:

[pax:~]% procinfo




On Linux systems, the procinfo command produces the following output:

[pax:~]% procinfo

Linux 2.0.36 ([email protected]) (gcc #1 Wed Jul 25 21:40:16 EST 2001 [pax]

Memory: Total Used Free Shared Buffers Cached

Mem: 95564 90252 5312 31412 33104 26412

Swap: 68508 0 68508





The w(ho) command produces the following output:

[pax:~]% w



mir ttyp0 :0.0 Fri10pm 3days 0.09s 0.09s bash

neil ttyp2 9:40am 0.00s 0.29s 0.15s w









Swap: 68508K av, 0K used, 68508K free, 14508K cched


5909 neil 13 0 720 720 552 R 0 1.5 0.7 0.01 top

1 root 0 0 396 396 328 S 0 0.0 0.4 0.02 init

2 root 0 0 0 0 0 SW 0 0.0 0.0 0.00 kflushd

3 root -12 -12 0 0 0 SW< 0 0.0 0.0 0.00 kswapd


1.2 GUI Output


Although such visual aids help us to see that the green curve is more spikey and has more variability than the red curve, and it allows us to see a complete day’s worth of data, it’s not clear how useful this is for capacity planning or performance analysis. We need to understand more about how the load average metric is defined and calculated.

2. So what is it?


Let’s look at the official UNIX documentation.

2.1 The man Page

[pax:~]% man “load average”

No manual entry for load average

Oops! There is no man page! The load average metric is an output embedded in other commands so it doesn’t get its own man entry. Alright, let’s look at the man page for uptime, for example, and see if we can learn more that way.







So, that explains the three metrics. They are the “... load averages for the past 1, 5, and 15 minutes.” Which are the GREEN, BLUE and RED curves, respectively, in Figure 1 above. Unfortunately, that still begs the question “What is the load?

2.2 What the Gurus Have to Say

Let’s turn to some UNIX hot-shots for more enlightenment.

Tim O’Reilly and Crew





time is correspondingly slow.

What’s high? ... Ideally, you’d like a load average under, say, 3, ... Ultimately, ‘high’ means high enough so that you don’t need uptime to tell you that the system is overloaded.

Hmmm ... where did that number “3” come from? And which of the three averages (1, 5, 15 minutes) are they referring to?

Adrian Cockcroft on Solaris



So, even the “big boys” at Sun can get it wrong. Nonetheless, the idea that the load average is associated with the CPU run queue is an important point.

O’Reilly et al. also note some potential gotchas with using load average ...


As I will demonstrate, this depends on when you look. If the CPU-bound process runs long enough, it will drive the load average up because its always either running or runable. The obscurities stem from the fact that the load average is not your average kind of average. As we alluded to in the above introduction, it’s a time-dependentaverage. Not only that, but it’s a damped time-dependent average. To find out more, let’s do some controlled experiments.

3. Performance Experiments


  • CPU was pegged for 2100 seconds and then the processes were killed.
  • CPU was quiescent for the remaining 1500 seconds.


3.1 Test Load


  1. The CPU is pegged by these tasks for 2,100 seconds.
  2. The CPU is (relatively) quiescent for the remaining 1,500 seconds.


3.2 Process Sampling


  • running i.e., currently executing on the CPU
  • runnable i.e., waiting in the run_queue for the CPU




601 */

602 static unsigned long count_active_tasks (void)

603 {

604 struct task struct *p;

605 unsigned long nr = 0;


607 read_lock (&tasklist_lock);

608 for_each_task(p) {

609 if ( (p->state == TASK_RUNNING | |

610 (p->state & TASK_UNINTERRUPTIBLE ) ) )

611 nr += FIXED_1;

612 }

613 read_unlock(&tasklist_lock);

614 return nr;

615 }

So, uptime is sampled every 5 seconds which is the linux kernel’s intrinsic timebase for updating the load average calculations.

3.3 Test Results



You would be forgiven for jumping to the conclusion that the “load” is the same thing as the CPU utilization. As the Linux results show, when two hot processes are running, the maximum load is two (not one) on a single CPU. So, load is not equivalent to CPU utilization.

From another perspective, Fig. 2 resembles the charging and discharging of a capacitive RC circuit.

4. Kernal Magic

Now let’s go inside the Linux kernel and see what it is doing to generate these load average numbers.

unsigned long avenrun[3];


625 static inline void calc_load(unsigned long ticks)

626 {

627 unsigned long active_tasks; /* fixed-point */

628 static int count = LOAD_FREQ;


630 count -= ticks;

631 if (count > 0) {

632 count += LOAD_FREQ;

633 active_tasks = count_active_tasks( );




637 }

638 }


1 HZ = 100 ticks

5 HZ = 500 ticks

1 tick = 10 miliseconds

500 ticks = 5000 miliseconds (or 5 seconds)


4.1 Magic Numbers

The function CALC_LOAD is a macro defined in sched.h










67 #define CALC_LOAD(load,exp,n) \

68 load *= exp; \


70 load >>= FSHIFT;




50 * counting. Some notes:

51 * — 11 bit fractions expand to 22 bits by the multiplies; this gives a

52 * load-average precision of 10 bits integer + 11 bits fractional

53 * — if you want to count load-averages more often, you need more



56 * 11 bit fractions.

57 */





4.2 Magic Revealed




load(t) = load(t-1) e-5/60 (4)


load(tT) = load(t0) e-5t/60 (5)



load(tT) = 2 load(t0) (1 - e-5t/60)     (6)


5. Summary




  1. The “load” is not the utilization but the total queue length.
  2. They are point samples of three different time series.
  3. They are exponentially-damped moving averages.
  4. They are in the wrong order to represent trend information.


Get started with a capacity management practice

Related Products

Related Solutions

Stay up to date on what matters.