The Multics Virtual Memory: Concepts and Design
Bensoussan, Clingen, Daley 1972
What kind of paper is this?
- Describes a system.
- Motivates and describes the VM system as a way to avoid what we think of
as linking in today's systems (or perhaps you could say that it provides
a general dynamic linking capability that replaces all forms of linking
we think of today).
Objectives
- Provide large virtual memories, but also support sharing:
- All information must be directly addressable (single level store;
mapping of all data).
- Must be able to control access to all the accessible information.
Claims
- Mapping data into memory, rather than requiring explicit IO is more
natural for the programmer.
- But, memory mapping also introduces the need for segment-level access
control.
- Comparison to earlier papers: "Although the Multics virtual memory
has been discussed elsewhere at the conceptual
level or in its earlier forms, the implementation presentcd
here represents a mechanism resulting from
several consecutive implementations leading to an
effective realization of the design goals."
- In other words, "We finally have it working now."
The challenge of Segmentation
- Sharing must be automatic and general
- No duplication of information
- Access control in both primary and secondary storage
- The authors talk about the extra work of the read-modify-write
cycle required in file-based systems. Can you think of any advantages
to the read-modify-write model?
- "As a consequence, nonsegmented
hardware is inadequate for controlled sharing
in core memory." I disagree: you impose access on which data can
be placed in a core image for a particular process and you've solved
this problem, so the claim here seems a bit overstated.
- How many segments is "sufficiently many?"
Hardware support
- Addresses are of the form: [segment, index-in-segment]
- Descriptor Base Register (DBR) provides address of the Page Table
for the register, and the number of entries in the page table.
- Descriptor Segment: 218-1 entries that map segment numbers
to segment descriptor words (SDW).
- SDW contains: missing bit (F), core address of the segment (core),
segment length (l),
access rights (acc).
- Pages are 1024 words.
- The ith word of a segment is on page P; offset W, where
P = I div 1024 and W = I mod 1024.
- Each segment is described by a Page Table.
- Page table: a set of physically contiguous words in core memory
containing page table words (PTW).
- PTW contains: F missing bit, address of the page (core).
- Something resembling a TLB that caches PTWs and SDW's recently accessed.
Software
- Process: A program in execution.
- Multics supervisor (kernel) also uses segment addressing.
- Supervisor code need not be permanently resident; it too can be
demand paged.
Segments
- Catalogue maps segment names to attributes (length, memory address,
permissions, time of access, etc). Sounds a lot like an dinode (called
a branch in Multics).
- Implemented in multiple segments (directories) organized as a tree.
- Introduction of hierarchically structured namespaces!
- Also introduces what we know now as symbolic links.
- Note the search rules that determine where you look for segments.
- Fault handling
- KST contains a pointer to the branch for each known segment.
- Active segment table (AST) occupies reserved memory; contains things
needed for page fault handling.
- AST contains an entry (ASTE) per page table.
- Page tables(ASTEs) divided into two lists: used and free.
- A segment with an ASTE is active (status recorded in branch) -- the
segment map and length have been moved into the ASTE (basically like reading
an on-disk inode, dnode, into the buffer cache).
- Once segments are set up, page fault handling occurs largely as it does
today.
- And replacement is implemented much as it is today as well: used bits
and something approximating LRU.
The Supervisor
- Three major components: Directory control, segment control, page control.
- Given the algorithms for segment fault handling and page fault handling,
we can derive the rules/assumptions/constraints on what has to be pinned in
memory and what can be moved in and out.
- From first principles, the authors derive these constraints:
- All segments used in Page Control (PC) are always in core and are
connected to the descriptor segment of each process. (I.e., page fault
handling code shouldn't be swapped out.)
- All non-directory segments used in SC and DC are always active and are
connected to the descriptor segment of each process.
- The root directory is always active and connected to each process.
- The root directory is always known to each process.