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