From: Nathan Dire (ndire_at_cs.washington.edu)
Date: Wed Feb 11 2004 - 14:24:11 PST
In "Machine-Independent Virtual Memory Management for Paged Uniprocessor and
Multiprocessor Architectures", Rashid, et al, present the virtual memory
system of CMU's Mach Operating System, and explain how the system was
architected to maximize portability.
Mach supports large, sparse virtual address spaces, copy-on-write virtual copy
operations, copy-on-write and read-write memory sharing between tasks, memory
mapped files, and user-provided back store objects and pagers. The size of a
Mach address space is limited only by the underlying hardware's support.
Tasks are allowed to modify their virtual address space, and tasks can share
memory as copy-on-write or read/write. For each page, inheritance may be
specified per-page as shared, copy, or none. Read/write/execute protection
may be specified per-page in current and maximum values.
The basic structures of Mach's virtual memory implementation are: the resident
page table, which keeps track of machine independent pages; address maps, or
lists of map entries which describe a mapping from a range of addresses to a
region of a memory object; memory objects, units of backing storage for pages;
and the pmap, which hold machine dependent mapping data.
Mach treats physical memory as a cache for the contents of vm objects. Each
physical page entry may be simultaneously lined into several lists: memory
object list, where all page entries associated with a given object are linked
together in a memory object list to speed up object deallocation and virtual
copy operations; a memory allocation queue, one each for free, reclaimable
which are used by the paging daemon; and an object/offset hash bucket which
allows fast lookup of physical pages at fault time. Byte offsets in memory
objects allow Mach to different page sizes.
To support copy-on-write, Mach has shadow objects, which are memory objects
that hold modified pages originally belonging to another object. The shadow
object only keeps the pages that have been written to, using the original
object for unmodified pages. To support read/write sharing of memory, Mach
has sharing maps, which provide a level of indirection in a task's address map.
The ability of the architecture to handle multiprocessors and distributed
operation seems quite forward-thinking for 1987. I'm curious why Mach was
able to use a file for swapping, while Linux and *BSD still require a separate
swap partition (as far as I know). Perhaps that's for performance.
A testament to the success of this design it's adoption for the VM systems of
4.4BSD Unix. In the version of FreeBSD that I work on, many of the structures
have remained almost unchanged from this implementation (as far as I can
tell).
This archive was generated by hypermail 2.1.6 : Wed Feb 11 2004 - 14:24:12 PST