Re: VM system

[newsham@uhunix.uhcc.Hawaii.Edu writes:]

> Worse I don't know much about the i386's
>MMU support (besides that it is supposed to be similar to
>the 68k's). Would anyone be kind enough to give me a quick
>overview of the VM system?

The Intel reference manual for the i486 has a pretty good description of the
x86 VM facilities.

>Such things as the VAS, the HAT,
>physical to virtual and virtual to physical translations and
>the i386's support (what are the functions of cr2 and cr3
>for example).

I'll write something up concerning the vas, hat, pset, pview, atl and
friends, but I think Intel did a better and more thorough job on the x86
than I'd care to do. Drop me a note if you want their phone # for ordering
a copy.

The "root" of the memory system is the "vas" struct, which stands for
Virtual Address Space. A vas hangs off the proc struct, as do thread
structs. Thus, a proc has a 1:1 connection to a virtual address space, and
all threads under a proc share the same address space.

A vas is mostly just a place list one or more pviews. It provides a mutex
(mutual exclusion mechanism) to coordinate changes made to the address
space, and it leaves room for the "hatvas", which is any hardware-specific
state which needs to be kept per address space.

"hat" stands for Hardware Address Translation. It refers to
processor-dependent virtual memory system functions.

Each pview exists under a single vas, and one or more pviews are linked
together in a list. Each pview describes a virtual address, and a length.
Thus, its name "Page View". The sum of all pview's address/length ranges
describes the virtual addresses which are valid in a particular address
space. The pview also describes protection (read-only, read-write, etc.).
Finally, the pview also points downward to a pset.

A pset is the first level which is not associated with a particular address
space. In fact, pviews from many different address spaces can point down to
a pset. The pset describes the state of a set of pages, and thus gets its
name "Page Set". A pset describes a length but no virtual address; a set of
pages can be mapped at different addresses in different address spaces. It
describes where initial page contents are accessed (from a server,
zero-filled, copy-on-write) and also maintains an array of per-page
information.

The "perpage" struct holds state for a particular page slot under a pset.
If the slot is valid, it names the physical page number. It also records
the pviews which currently have a mapping to this page. The "atl" ("Attach
List") is a linked list data structure which then enumerates each such
pview. The ability to enumerate mappings of a physical page is required by
the two-handed clock algorithm used to age pages during memory pageout and
reclaim.

Finally, each physical page has a corresponding "struct core" entry. This
entry records information needed to "wire" a page (keep it from being
reclaimed--needed during DMA access, for instance). It also provides a back
pointer to the pset which is currently using this page.

The i386-specific portion of the VM data structures is minimal. The
"hatvas" struct keep both the virtual and physical addresses for the root of
the page tables for a given address space. It keeps a resource map to
tabulate what addresses are available for dynamic memory. Finally, purely
as an optimization, it keeps a bitmap to indicate which slots in the root
page table have second level page tables. This is used to speed cleanup
during exit().

Some brief notes on the mutex design. The vas has a spinlock which protects
changes to the overall address space. The pview does not; cases where it
needs to be protected are covered by acquiring the vas's spinlock. The pset
has a of two mechanisms. For simple changes like reference count updates it
has a straight spinlock "p_lock". For changes to some particular position
under the pset, the effect of having a per-slot semaphore (sleeping mutex,
not spin-oriented) is gained using a combination of the pset's p_lockwait
semaphore and two bits in the pp_lock field of the perpage information.
PP_LOCK in this field indicates the the slot is held. PP_WANT is an
optimization which indicates that on release of PP_LOCK, if PP_WANT is set
then sleepers on p_lockwait in the containing pset will be awaken.

Thus, pageins of multiple positions within a pset can be done in parallel.
Two threads racing to page in a single position will be serialized on the
PP_LOCK of the slot. Removing a pview from a vas will be protected by the
vas's spinlock. The fact that multiple threads can be changing a vas (and
structures below) asynchronously adds complications. For instance, deleting
a pview from a vas requires great care so that threads already active down
in the pset are not hosed when a thread starts removing the pview form the
vas, and tries to tear it down.

                                                        Andy
Received on Wed May 18 10:02:42 1994