evals for 5/9

Yod (h13nguye@ieng9.ucsd.edu)
Mon, 8 May 2000 21:12:39 -0700 (PDT)

Title: Why Aren't Operating Systems Getting Faster As Fast as Hardware?

As the raw CPU power increases, the usual tendency is to think that the speed
of the operating system functions would also increases proportionally. This
paper, evaluates several hardware platforms and operating systems, demonstrates
that improving raw CPU power does not necessarily increases the speed of the
operating system functions. The benchmarks that were used in this paper were
stress kernel entry/exit, file systems, and other things related to operating

By the title of the paper, one would know that the author argument would be
that the operating system performance is not improving at the same rate as the
base speed of the underlying hardware. Throughout the paper, evidents such
as graphs and tables were used to support the argument presented by the paper.

The first benchmark that was being tested is the kernel Entry-Exit. This is
done by repeatedly involking the getpid kernel call. The data for this test
shows that the RISC machines were generally faster than the CISC machines on an
absolute scale, but they were not as fast as their MIPS ratings would suggest.
Entering and exiting the kernel in the RISC mahines has not improved as much as
their basic computation speed. Similar results were seen in the test for
Context switching, where RISC machines were generally faster than CISC machines,
but the factor of increase in performance is belowed the expected level.

In memory related tests, block copy and read from file cache, faster machines
did not scale well against the slower machines. In the case of the block copy
test, the factor for their performance were due to the cache organizations and
memory bandwidths of the different machines. For the read from file cache, the
determined factor was the implementation of write-back cache over the write-
through caches. For these two tests, increases in performance of the speed of
the CPU did very little to increase the performance of the functions.

In other tests, Open-Close and Create-Delete, results showed that the Sprite
file system is faster than the other file systems, particularly for remote
access. Because Unix and its derivatives are all much more disk-bound than
Sprite, file creation and deletion is much slower than Sprite.

The paper concludes that faster system must improve memory bandwidth and reduce
operating systems' tendency to wait for disk operations to completely enhance
its overall system performance.

Title: The Interaction of Architecture and Operating System Design

This paper analyzes system performance of various OS designs. The paper
compares the performance of these systems through their interprocess
communication (IPC), virtual memory, and thread management. The systems that
were under scrutinied are: DEC CVAX, Motorola 88000, MIPS R2000, MIPS R3000,
and the Sun SPARC.

IPC => (1) Cross-Machine Communication - Background: most systems now support
RPC, and what it does is that it encapsulates message-oriented communication
in procedure call semantics. Communication performance is not limited by
network speed, but also involves the operating systems between the client and
the server. Result: improvements in CPU speed do not equally reflect in the
performance of its RPC, due to the fact that system calls and traps do not
scale equally as well. The bound on RPC performance, according to the author,
will be due to the cost of operating system primitives that include interrupt
processing, thread management, and memory-intensive operations.

(2) Local Communication - Using LRPC to determine how effectively the OS can be
decomposed, as well as how rapidly clients can communicate with local servers.
According to the author findings, with LRPC, the real factor limiting perfor-
mance is the hardware cost of communicating through the kernel. Unfortunately,
kernel bottleneck is even worse on newer architectures, because the overhead of
system calls and context switching has not decreased proportionally with over-
all processor speed.

Virtual Memory => Background: the basic use of VM is to support address spaces
larger than the physical memory. The main issues are the flexibility of the
addressing mechanism, the information provided by that mechanism, and the ease
of handling faults and changing hardware VM addressing state. Result: many
new architectures simplified memory management, but, at the same time, they
also add significant complexity and latency to the memory management task.
The existence of pipelining in newer architectures complicates the design of the
OS to handle and manage the pipeline when an exception arises. But some new
RISC architectures moved TLB management into software, which allow the OS to be
free in choosing whatever page table structure it likes, and handling of sparse
address spaces is greatly simplified.

Thread and Multiprocessing => Barckground: Threads, which can be supported by
the OS or by the application run-time level, allow the programmer or compiler
to express, create, and control parallel activities, contributing to the
structure and performance of parallel programs. In this area, the paper
concludes that new architecture designs and new OS designs moved at cross pur-
poses. While architectural mechanisms tried to improve speed up the execution
of sequential programs, OS have been changing to support parallelism through

The author believes that the lack of communication between system architect and
OS designer is the culprit. hahaha...Modern systems: CPU is approaching light
speed, more and more memory is available, Quake III is much better than II, so
what is the fuss..