From: Gail Rahn (grahn_at_cs.washington.edu)
Date: Sat Feb 14 2004 - 16:53:47 PST
Review of "Virtual Memory Management in VAX/VMS"
This paper describes the memory management design of VAX-11 minicomputers,
released in 1978 and 1980. The family of VAX-11 computers were 32-bit
mainframes that ran both interactive and batched applications. The
memory-management design must be capable of supporting many applications
and variant hardware configurations.
VAX-11 computers had a 32-bit address space divided into 512-byte pages.
Here, a page is the atomic unit for protection. Each 32-bit address is
split into 21-bit virtual page number and a 9-bit page offset.
The virtual address space is divided into four sections:
(a) P0: Program region, addresses from 0, grows with increasing
addresses.
(b) P1: control region, addresses from 2^31, grows with decreasing
addresses.
(c) System Region, addresses from 2^31, grows with increasing
addresses. This address space is shared by all processes in the system.
(d) Unused: addresses >= 2^31 + 2^30.
Each region of virtual memory is defined by a page table. Each page table
entry contains bits for validity, pritection, tracking modification and the
mapping to the physical page frame number. A page table is defined by two
register values: the base address of the table and its length. The system
and process page tables are located in the system-space section of the
memory address space. The page tables for P0 and P1 memory are
process-specific, so the locations and offsets of these tables must be
updated when switching contexts. Additionally, the VAX hardware provides a
translation buffer that caches virtual and physical memory mappings.
The VAX memory-management system had to be able to run on heterogeneous
hardware environments and in medium- to low-strength computing systems, so
there were significant design concerns to be mitigated and addressed,
including performance on heavily-paged programs, program startup cost,
increased disk overhead and processor time incurred by paging. Memory
management was divided into two components: the pager and the swapper.
The pager is responsible for loading and removing process memory pages into
memory. The swapper is responsible for performning context switches -
loading and removing processes into and out of memory. The pager executes as
part of the process. The swapper is a separate software process.
The pager implements a "process-local" page replacement policy. That is,
processes are allocated a specific number of pages in virtual memory (the
resident-set) and when a page must be removed from memory, the pager chooses
from the resident-set of the process requesting the new memory. Memory
access speedups came from the queueing of discarded pages and page
clustering. The free list contains a FIFO list of pages no longer in use by
the VM system. The modify-list contains a FIFO list of memory pages that
have been modified, and the VM system queues the list for writing back to
memory. Both lists also function as second-level memory caches. When a page
fault occurs, the VM system checks both lists for the presence of the
desired page. When retrieving a page from memory, clustering the request to
read and write several sequential pages into/from memroy simultaneously has
also been seen to decrease page faults.
The swapper handles swapping the resident-sets of processes between memory
and backing stores. When a process is removed from memory, its resident-set
is written to a swap file. An incoming process has its page-table and
resident-set entries written again into memory. The swapper also creates an
initial execution environment for a new process.
Gail Rahn
grahn_at_cs.washington.edu
This archive was generated by hypermail 2.1.6 : Sat Feb 14 2004 - 16:54:00 PST