Review: Why

Arent Operating Systems Getting Faster as Fast as Hardware? and

The Interaction of Architecture and Operating System Design

Aizelle Marie Borja

1 Summary
This review states the point of John Oustehout in their research entitled Why Arent Operating Systems Getting Faster as Fast as Hardware? and also the research of Thomas Anderson et al The Interaction of Architecture and Operating System Design. Both research discussed why inspite of a high quality performance of a computer specially in

processor speed and an Operating System with multiple features still it will have an implications. As Anderson and his colleagues discuss about the relationship between the Operating System and hardware support while Ousterhout demonstrated that operating systems are not receiving the same benefit as applications from new hardware platforms.

1.1

Motivation
Both research stated the implications and factors behind the slow processing of

Operating system behind the advancement of hardware platforms. In order to have a compatible Operating sytem and hardware platforms, it is a challenge to the developers of

Operating System and the architects of modern computer to have the operating sytem and hardware platforms compatible with each other.

1.2Contribution
Ousterhout used a set of benchmarks that test memory bandwidth and various operating system features [Ousterhout, 1990]. It is the basis of Anderson and his colleagues that inspires them to add areas in which operating system design could accommodate (and cost-effectively) accommodate operating system needs, and areas in which operating system design could accommodate certain necessary characteristics of cost-effective high-performance microprocessors [Anderson et al, 1991].

1.3Methodology
The table below shows the different hardware platforms use by the authors. They both use RISC/CISC hardware platforms.

Ousterhout used Hardware platform and Operating System

Hardware Platforms
MIPS M2000 DEC station 3100 SUN-4/280 VAX8800 SUN-3/75

Operating System
RISC/os 4.0 Sprite; Ultrix 3.1 SunOS 4.0;Sprite Ultrx 3.0i Sprite; SunOS 3.5

Ousterhouts Study
He uses several benchmarks to test the speed of the operating systm. Benchmarks
exercises are follows: (a.) Kernel Entry-Exit- first benchmarks measures the cost of entering and leaving the operating system kernel. (b.) Context Switching, it measure the cost context switching plus the time for processing small pipes read and write, operates by forking a child process and then passing one byte back and forth between parent and child using pipes. c.) Select, it creates number of pipes, places data in some of those pipes and then repeatedly calls select to determine how many of the pipe are readable in observation. (d.) Block Copy, transfer large blocks of data from one area of memory to another, this benchmark doesnt exercise the operating system at all. (e.) Read from file cache, consist of a program that opens a large file and reads the file repeatedly in 16-kbyte blocks. (f.) Modified Andrew Benchmarks, developed by M. Satyanarayanan for measuring the performance of the Andrew file system, it operates by copying a directory hierarchy containing the source code for a program, stat-ing every file in the new hierarchy, reading the contents of every copied file, and finally compiling the code in the copied hierarchy. (g.) Open-Close, which repeatedly opens and closes a particular file. (h.) CreateDelete, was perhaps the most interesting in terms of identifying differences between operating systems, it simulates the creation, use, and deletion of a temporary file. It opens a file, writes some amount of data to the file, closes the file, then opens the file for reading, reads the data, closes the file, and finally deletes the file. The following are the highlights RISC/CISC machines in different benchmarks. (a.) Kernel Switching, in this first benchmark the entering and leaving the operating system in RISC machines indicates that the cost for entering and exiting the kernel has not improve as their basic computation speed. (b.) Context Switching, it has two context switches and one read and one write kernel call in each process, MIPS relative speed were computed by scaling the Sun3 times MIPS ratings once again the RISC machines didnt perform as well as might expected, Except for

the DS3100/Ultrix combination. (c.) Select, M2000 numbers are surprisingly high for pipes that were empty. But quite los as long as al least one of the pipes contain data. (d.) Block Copy, after computing the values, 8800 value is (16/6) = 2.7. The most interesting thing to notice is that the CISC machines (8800, Sun3, and MVAX2) have normalized ratings of 2.5-4, whereas the RISC machines have ratings of 0.4-1.0. For the DEC and Sun RIS workstations, faster processors do not appear to have been accompanied by any increase in memory bandwidth. Thus, memoryintensive applications are not likely to scale on these machines. In fact, the relative performance of memory copying drops almost monotonically with faster processors, both for RISC and CISC machines. (e.) Read from File Cache, in this benchmark Sun4 standout better due to its writeback cache. Since the receiving buffer always stays in the cache, its contents get overwritten without ever being flushed to memory. (f.) Modified Andrew Benchmark,in this stage there some os that give surprise for their performance, first of all, no operating system scaled to match hardware speedups. Second, Sprite comes out consistently faster than Ultrix or SunOS for remote access. Sprite shows hardly any performance degradation for remote access, and for the compilation phase Sprite was faster remote than local. In contrast, NFS-based RISC workstations slow down by about 50% relative to local access. It appears to me that the relative penalty for using NFS is increasing as machine speeds increase. The third interesting result of this benchmark is that the DS3100-Ultrix combination is somewhat slower than would have been expected. For example, DS3100-Ultrix-Local is about 70% slower than DS3100-Sprite-Remote, and DS3100-Ultrix-Remote is not much faster than Sun4-SunOS-Remote.

Andersons group used Hardware platform and operating system.

Hardware Platforms
VAXstation 3200 Tektronix XD88/01 DECstation 3100 DECstation 5000/200 SPARCstation 1+

Operating system UNIX UNIX UNIX UNIX UNIX

Study of Thomas Anderson & his Colleagues

Andersons group compared the performance of several microprocessors executing the following primitive operating system functions: (1.) Null system call, the time for a user program to enter null C procedure in the kernel, with interrupts (re-)enable, and then return. (2.) Trap, the time for user program to take a data access fault (e.g., on a protection violation), vector to a null C procedure in the kernel, and return to a user program. This requires saving and restoring any registers that are not preserve across procedure calls. (3.) Page Table Entry Change, the time, once in the kernel to convert a virtual address into its corresponding page entry, update that entry to change protection information, and then update any hardware (the translation buffer) that caches the information. (4.) Context Switch, the time, once in the kernel, to save once process context and resume another, including time to change address spaces in hardware. Andersons group provided the discussion on the components of operating system design. The Interprocess Communication were operating system evolved to a more decentralized structure, it instructing the operating system as independent address space communicating trough message modularity, fault tolerance and extensibility enhanced and use message as a principal communicating mechanism. The Cross-Machine Communication, uses RPC (Remote Procedure Call) to communicate between address spaces, it encapsulates message oriented

communication in procedure call semantics. The Local Communication (Local calls address space) it determines how effectively the operating system can decompose and how clients rapidly can communicate with local servers. The Virtual Memory, Use to transparently support parallel programming across networks was operating system demands on virtual memory to enhance system performance [Anderson et al, 1991].

1.4 Conclusions
The research of two authors further explained the thing that should do of the developers and architectures of Operating system. In hardware side, memory bandwidth has been allowed to slip relative to processors speed.Software side, operating system designer need to decouple file system performance from disk performance, if this decoupling isnt eliminated a large class of file intensive programs will receive no benefit from hardware. Area Network protocol, if users are to benefit from faster machines, either NFS must be scrapped or change to less synchronous. This are the content of Ousterhout research while Anderson and his colleagues states that Operating system needs needs in 3 fundamental areas and those operating systems are decomposed into kernelized structures with independent server executing inseparable address space. Operating system requires more memory management, at the time when events has become more difficult. Operating system are moving forward to support fine grain muti-threaded application program at the same time architectures are adding more processor state which make threads more expensive.

2 Critique
The papers of Ousterhout , Andersons and colleagues has a similarity in understanding both topics about hardware platforms and operating system designs in focus to operating system performance. As of now different kind of high-performance microprocessors, architectures have paid less attention to operating system performance where new operating system architecture have overlooked modern architectural trends which change the relative cost of certain performance of microprocessors the comparison of different RISC/CISC machines to understand whether or not

operating system sale with the base performance of hardware platform, some machines standout but it does not satisfy the expected performance, with the discovery of areas, limitation of hardware and the requirements of operating systems in order that operating system have a good performance it does not depends for operating system but the overall parts of a machine with the help of the memory to restore and release a hardware platform that may support multi-threaded process will accommodate the problems in operating systems.

3 Synthesis
The discussion of the two author give a broad explanation about the computer hardware
platform and operating system design though theyre focuses only in areas, domains, design of operating systems and hardware platforms will may have a great help for those designer who needs several ideas from different sources.