Reduction Hardware Support and Co-Design

significantly higher high-water mark. This creates breathing room and ensures that the costly resource reclamation procedure is not called again too soon. The problem is of course that sometimes the load on the system indeed needs more resources than are available. The solution in this case is — if possible — to forcefully reduce the load. For example, this is the case when swapping is used to escape from thrashing, or when a system uses admission controls. Define your goals The most common approach to resource management is to strive for “fairness”. This is essentially equivalent to “best effort” and “graceful degradation”. The idea is that the system is not judgmental — it tries to give good service to all, regardless of their standing and behavior. Recently there is more and more emphasis on differentiated services, meaning that different processes or users receive different levels of service. This may be based on administrative considerations, as in fair-share scheduling, or on technical considera- tions, as when trying to meet the real-time needs of multimedia applications. The distinction between these two approaches is important because it dictates the mechanisms that are used. If the goal is to serve all users, then approaches such as partitioning resources into ever smaller portions are justified. But if quality of service is paramount, there is no escape from using admission controls.

8.3 Reduction

Problems don’t always have to be solved from basic principles. On the contrary, the best solution is usually to reduce the problem to a smaller problem that can be solved easily. Use Conventions Sometimes it is simply impossible to solve a problem from first principles. For ex- ample, the problem of finding any file or directory is solved by using a hierarchical directory structure. But this ceates a cycle because we need to be able to find the first directory in order to start the procedure. Thus we need some help from outside of the domain of directories. The simplest solution to this reduced problem find the first directory is to use conventions. Such conventions are globally useful for priming a search: • The inode of root is 2. • Network address lookups start from the root DNS. • Predefined port numbers represent well-known services. 172 Use Amplification Amplification is a more general mechanism. The idea is again to use a simple solution to a simple problem, and amplify it in order to solve a larger problem. • The atomic test-and-set instruction can be used to implement the more general abstraction of a semaphore. • A name server is the only service you need to know about initially. You can then use it to gain knowledge about any other service you might need. • When booting the machine, you don’t start the full operating system in a single step. You first use a small program stored in ROM to load the boot sector from the disk. This contains a larger program that can start up the operating system.

8.4 Hardware Support and Co-Design

Some theoreticians like challenging models of coumputation in which the application considers the operating system and hardware to be adversaries, and has to do every- thing by itself. In real life, it is better to use all the help you can get. The hardware is your friend Specifically, operating systems have and will continue to be co-designed with hard- ware. Always look for the simple solution, and exploit whatever the hardware pro- vides. If it does not yet provide what is needed, it might in the next generation espe- cially if you ask the hardware designers. One example comes from the early support for paging and virtual memory on the VAX running Unix. Initially, hardware support for mapping was provided, but with- out use bits that can be used to implement replacement algorithms that appriximate LRU. The creative solution was to mark the pages as absent. Accessing them would then cause a page fault and a trap to the operating system. But the operating system would know that the page was actually there, and would simply use this page fault to simulate its own used bits. In later generations, the used bit migrated to hardware. Another example comes from concurrent programming. True, it is possible to de- vise clever algorithms that solve the mutual exclusion problem using only load and store operations on memory. But is is much easier with instructions such as test-and- set. Finally, many aspects of IO control, including caching and disk scheduling, are migrating from the operating system to the disk controllers. As a side note, migration from the operating system to user applications is also im- portant. Various abstractions invented within operating systems, such as semaphores, are actually useful for any application concerned with concurrent programming. These should and have been exposed at the systems interface, and made available to all. 173 There are numerous examples of hardware support Here is a list of examples we have mentioned for the close interactions of hardware and the operating system: • Kernel execution mode – The interrupt vector, enabling the registration of operating system func- tions to handle different interrupts – The trap instruction to implement system calls • Clock interrupts to regain control and support timing functions • Support for concurrent programming – Atomic operations such as test-and-set – The options of blocking interrupts – DMA to allow IO to proceed in parallel with computation, and interrupts to alert the system when IO operations have completed • Support for memory mapping – Address translation that includes protection and page faults for unmapped pages – The ability to switch mappings easily using a register that points to the base address of the pagesegment table – The TLB which serves as a cache for the page table – Updating the usedmodified bits of pages when they are accessed • Help in booting the machine Bibliography [1] R. H. Johnson, MVS: Concepts and Facilities. McGraw-Hill, 1989. 174 Part III Real Stuff The classical operating system curriculum emphasizes major concepts and ab- stractions, and the intellectual achievements in their design. However, this is some- times divorced from what real systems do. First, there are lots of technical issues that simply don’t have much lustre. How- ever, you need to know about them to really understand how the system works. Second, there is the issue of supporting multiprocessor systems. In part II we limited the discussion to systems with a single processor, but this is increasingly anachronistic. Servers have employed symmetric multiprocessing for years, and in recent years even desktop machines are using hyperthreading and multicore proces- sors. This provides the opportunity to review all what we learned with the added perspective of how to adjust it to support true parallelism. Third, there is the question of structure. An operating system is a large and com- plex program. Therefore organization, bookkeeping, and structure are just as impor- tant as using great algorithms. Chapter 9 Technicalities The previous chapters covered the classical operating system curriculum, which em- phasizes abstractions, algorithms, and resource management. However, this is not enough in order to create a working system. This chapter covers some more technical issues and explains some additional aspects of how a computer system works. Most of it is Unix-specific.

9.1 Booting the System