From: Raz Mathias (razvanma_at_exchange.microsoft.com)
Date: Wed Feb 11 2004 - 17:15:05 PST
This paper presents an encompassing view on paging using the particular implementation of the VAX/VMS system. This short paper compactly covers a wide breadth of issues and considerations in building a virtual memory system.
The system consists of two managers, the pager and the swapper. The pager's responsibility is to fault pages into memory, that is, when an application touches a virtual address that doesn't translate into a physical address via the page table system, the pager comes online and brings the page off of disk and into memory. The basic hardware support on the VAX/VMS involves a system page table base register, which points to a location in physical memory containing the system page table. It was interesting to find out that the user mode process's page table actually lives in the system virtual memory space. Therefore, without caching, it actually takes two memory references to get to a single virtual address in the user process. The TLB optimizes the memory-access procedure by allowing us to cache entries in page tables. The paper introduces the concept of a "resident set" (also called the working set) which is the number of pages that are currently in memory. The system introduced a per-process limit on the resident set which resulted in a local-page-replacement algorithm, in which a process (rather than the system as a whole) needs to swap out a page from its working set in order to use a new page. This reminds me of a talk by Mark Russinovich in which I learned that Windows uses local page replacement whereas Linux uses a global page replacement algorithm; according to that talk it is unclear which is better in a "general sense." It would be nice to discuss this topic in class.
A few optimizations were discussed. The pager maintains both a free page list and a modified page list. When pages are read from disk they are read into memory from the free page list. The optimization comes from the fact that if the system needs to page memory for a page that's already in the free list, the free list can be used as a cache. The modified list is used to batch writes to the disk, thereby hopefully reducing the total disk seek time and increasing system throughput.
The second manager in the system is the swapper. The swapper's basic responsibility was to swap out all of the pages belonging to a particular process. This is done to speed up high-priority processes and reducing the disk usage by increasing the amount of primary memory available and reducing the amount of paging. The modified-list optimization is used here to batch writes to the disk.
In some ways, virtual memory implements a variation on the single-level store theme. To the user-mode application, memory and disk are indistinguishable. It is the kernel's responsibility to make sure that the disk is utilized efficiently. Another familiar thread is the idea of protection, which unlike in the Opal system is completely controlled by the address space (i.e. with virtual memory, protection is not orthogonal to memory usage). A process "lives" in its own 32-bit address space. Another theme is the idea of naming. In the Hydra (single-level-store) system we saw that names are actually string paths for referencing objects. Virtual memory is more similar to Opal, in that pointers are names to objects, regardless of whether they live in memory or on disk in the memory system (although in VM system, threads in different processes cannot share these names).
This archive was generated by hypermail 2.1.6 : Wed Feb 11 2004 - 17:15:30 PST