|  | |||||||||
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
ABSTRACT
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
complete.
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.
e
c
n
a
m
r
o
f
r
e
P
e
v
i
t
a
l
e
R
MIPS
1.2
1.0
0.8
0.6
0.4
0.2
0.0
20181614121086420
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