Reviewed by Yin Zhang, Feburary 16 1998
So far, we've learned many system design principles including "End-to-En d Argument", "Make the common case fast" etc. All such princi ples can be summarized as one word: Be GREEDY! That is, we should try to get the most profit with the least effort. A direct corollary is that we shoul d be LAZY -- only do things when you have to.
There is usually some tradeoff here: With more effort, you can usually (not always!) get more profit, but such gains should outweigh your extra effort! In this presentation, I will concentrate on such tradeoffs as I examine the design and implementation of virtual memory management within the CMU Mach Operating System .
Tradeoff 1. Portablility vs. Performance
One of the major goals of Mach is to achieve high portability. For this reason, the code for virtual memory management in Mach is split into three parts:
To achieve high portability, the machine-dependent part (pmap module in Mach) should be kept rather small and hence the driving force is the machine independent operati ons. But machine independence usually means failure to fully exploit the poten tial of particular machine hardware, and hence inferior performance.
Although the performance given in the paper is quite impressive, it's not ful ly convincing (at least for me). As illustrated the second paper to be presen ted today ("Virtual Memory Primitves for User Programs"), the performance of VM primitives provided in Mach is the worst compared with many other systems.
Question 1: Do you have more information about the performance of Mach?
Tradeoff 2. Hierarchical Structure vs. Flexibility
As shown in Tradeoff 1, the general structure of Mach's VM management part is basically (not fully!!) hierarchical. To make the idea of an extern al pager work, a strict protocol is used for communications between the kernel and the ex ternal pager. The protocol is illustrated in Table 3-1 and Table 3-2 of the paper .
However, the kernel can send a message to an external pager. This is ef fectively an upcall, and hence a violation of hierarchical structure. On th e other hand, such upcalls provide much flexibility. Again we need a tradeoff.
Question 2: Do you think the flexibility provided by the upcall in Mach is worth the violation of the hierarchical structure? (I think so. H ow about you?)
Tradeoff 3. Copying vs. Sharing (about copy-on-write polic y)
Mach supports the copy-on-write virtual copy operations. The basic idea behind such operations is simple: Be LAZY! If you don't need to do a copy, why bother? By using sharing instead of copying, we can eliminate some unneces sary copying. However, this is not without cost. Now the kernel has to ma intain information about which pages of a memory object have been modified and which ha ve not. This is non-trivial if the virtual memory is huge!
Whether such extra efforts pay depends on the size of the memory object to be shared, the possibility of write on such memory objects etc. But that there is no such statistics in the paper. (Of course the designer may have done such kind o f experiments but simply fail to include such results into the paper.)
Moreover, to my understanding, the copy-on-write operations are quite fine-gr ained, basically on the level of page. That is to say, if a task needs to write o n many pages, multiple traps are necessary. For many (most?) hardware architectur es, it would be far more efficient to copy the whole memory object when the first trap occurs (as long as the memory object is not too huge.)
Question 3: What's your impression about the copy-on-write oper ations? Is it worth the cost of complicating the kernel? On page 38, the la st paragraph of Section 6, authors mentioned the implementation of shared copy-on-reference data in a network or loosely coupled multiprocessor. Do you think it a good idea?