When the Unix load average was added to Unix

April 2, 2015

For reasons beyond the scope of this entry itself, I recently became curious about when the concept of 'load average' first appeared in Unix. Fortunately we have the Unix tree from the Unix Heritage Society, so I can answer this question by digging through various historical Unix trees.

The answer appears to be that the concept of load average appears first in 3BSD. In the 3BSD /usr/src/cmd directory, uptime.c is allegedly dated to October 4th 1979. The 3BSD kernel source for vmsched.c already has the normal definition of load average; it counts both runnable processes and processes waiting in uninterruptible sleep (which is theoretically always a short term thing). I believe that 3BSD also marks the appearance of vmstat.

As far as I can tell, V7 Unix lacked both an uptime command and any kernel support for accumulating the information. I was going to say that V7 didn't have any way to see how loaded your system was, but it does have a basic version of iostat and the kernel kept some degree of information about things like system versus user time, as you can see from the iostat manpage.

My personal suspicion is that 3BSD grew support for keeping track of how loaded the system was (via both uptime and the more detailed vmstat) because Berkeley started using 3BSD for undergraduate computing in student labs, where you could not simply ask your colleagues if someone was running something big and could they stop for a while if so. But I don't actually know if Berkeley was using 3BSD in undergrad labs this early on or if they only started doing it a few years later with 4BSD et al.

(UCB may also have wanted to have some idea of how well their new paged virtual memory system was working in practice.)

As as side note, I do like the BUGS section of the 3BSD vmstat manual page (at the end):

So many numbers print out that its sometimes hard to figure out what to watch.

This has only become more true over time.


Comments on this page:

By Mark T. Kennedy at 2015-04-02 06:44:43:

research computer science departments in the mid-to-late 70's, particularly ones connected to the ARPAnet, often had DEC20 'mainframes'. and DEC20's (and probably DEC10's or MIT ITS instances) all had the notion of 'load average'. almost surely it was imported from that environment just like many of the ideas in tcsh, the mmap library call (which you can trace back through DEC20's to multix), etc.

I don't know when it first appeared in Unix (especially AT&T Unix) but Chap. 6 of my book <http://www.perfdynamics.com/iBook/ppa_new.html> investigates what the load average metric actually measures by analyzing the kernel code in Linux (available online with hyperlinks). In its original form, that metric turns out to be the exponentially damped moving average of the run-queue length. The AT&T and BSD codes are very likely similar, although I don't have proof. Somewhere along the line, I saw (unexpectedly) that FreeBSD had hooks for the LA metric but no implementation.

As a side effect of investigating the historical origins of the LA code (which was something of an issue at the time I was writing my book due to the SCO law suit), I discovered that the LA not only derived from the CTSS (multi-user time share project) at MIT c. 1965 (which begat Multics, which begat Unix), but it is actually the first O/S performance metric of any kind. See "The Instrumentation of Multics" (CACM 1970) <http://www.multicians.org/InstrumentationPaper.html> for a defense of why performance instrumentation was such a good idea.

Written on 02 April 2015.
« Btrfs's mistake in limiting itself to two-way mirroring
Understanding the (original) meaning of Unix load average »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Apr 2 01:14:46 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.