page 1  (10 pages)
2to next section

USENIX Summer Conference

June 11-15, 1990

Anaheim, California

Why Aren't

Operating Systems

Getting Faster As

Fast as Hardware?

John K. Ousterhout - University of California at Berkeley


This paper evaluates several hardware platforms and operating systems using a set of benchmarks

that stress kernel entry/exit, file systems, and other things related to operating systems. The

overall conclusion is that operating system performance is not improving at the same rate as the

base speed of the underlying hardware. The most obvious ways to remedy this situation are to

improve memory bandwidth and reduce operating systems' tendency to wait for disk operations to


1. Introduction

In the summer and fall of 1989 I assembled a collec-

tion of operating system benchmarks. My original intent

was to compare the performance of Sprite, a UNIX-

compatible research operating system developed at the

University of California at Berkeley [4,5], with vendor-

supported versions of UNIX running on similar hardware.

After running the benchmarks on several configurations I

noticed that the ``fast'' machines didn't seem to be run-

ning the benchmarks as quickly as I would have guessed

from what I knew of the machines' processor speeds. In

order to test whether this was a fluke or a general trend, I

ran the benchmarks on a large number of hardware and

software configurations at DEC's Western Research

Laboratory, U.C. Berkeley, and Carnegie-Mellon Univer-

sity. This paper presents the results from the benchmarks.

Figure 1 summarizes the final results, which are con-

sistent with my early observations: as raw CPU power

increases, the speed of operating system functions (kernel

calls, I/O operations, data moving) does not seem to be

keeping pace. I found this to be true across a range of

hardware platforms and operating systems. Only one

``fast'' machine, the VAX 8800, was able to execute a

variety of benchmarks at speeds nearly commensurate

with its CPU power, but the 8800 is not a particularly fast

machine by today's standards and even it did not provide

consistently good performance. Other machines ran from

10% to 10x more slowly (depending on the benchmark)

than CPU power would suggest.

The benchmarks suggest at least two possible factors

for the disappointing operating system performance:

memory bandwidth and disk I/O. RISC architectures

have allowed CPU speed to scale much faster than

memory bandwidth, with the result that memory-intensive

benchmarks do not receive the full benefit of faster CPUs.

The second problem is in file systems. UNIX file systems

require disk writes before several key operations can

complete. As a result, the performance of those opera-

tions, and the performance of the file systems in general,

are closely tied to disk speed and do not improve much

with faster CPUs.











Figure 1. Summary of the results: operating system speed is not scaling at the same rate as basic hardware speed. Each point is the geometric mean of all the MIPS-relative performance numbers for all benchmarks on all operating systems on a particular machine. A value of 1.0 means that the operating system speed was commensurate with the machine's basic integer speed. The faster machines all have values much less than 1.0, which means that operating system functions ran more slowly than the machines' basic speeds would indicate.

The benchmarks that I ran are mostly ``micro-

benchmarks'': they measure specific features of the

hardware or operating system (such as memory-to-

memory copy speed or kernel entry-exit). Micro-

benchmarks make it easy to identify particular strengths

and weaknesses of systems, but they do not usually pro-

vide a good overall indication of system performance. I

also ran one ``macro-benchmark'' which exercises a

variety of operating system features; this benchmark

gives a better idea of overall system speed but does not

provide much information about why some platforms are

better than others. I make no guarantees that the collec-

tion of benchmarks discussed here is complete; it is