Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!sdcsvax!darrell
From: darrell@sdcsvax.UUCP
Newsgroups: comp.os.research
Subject: Re: Life with TLB and no PT
Message-ID: <3100@sdcsvax.UCSD.EDU>
Date: Wed, 6-May-87 22:07:04 EDT
Article-I.D.: sdcsvax.3100
Posted: Wed May  6 22:07:04 1987
Date-Received: Fri, 8-May-87 05:34:25 EDT
Sender: darrell@sdcsvax.UCSD.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 51
Approved: mod-os@sdcsvax.uucp


>Actually, an alternate view of the Sun MMUs is that they are very large
>software-managed TLBs done in a slightly unusual way.  The first stage
>of address translation (segment map) is the equivalent of the associative
>lookup of a more orthodox TLB.  The second stage (page map) is identical
>to normal TLB address translation.  The correspondence is actually quite
>close, to the point where one can envision semi-portable memory-management
>code that treats the Sun MMU as if it were a big TLB.
	...
>				Henry Spencer @ U of Toronto Zoology
>				{allegra,ihnp4,decvax,pyramid}!utzoo!henry

The Mach virtual memory implementation has been ported to many widely
varying architectures.  It makes no assumptions about a hardware MMU and in
essence treats whatever MMU may exist as a TLB (think of it as a multi-level
TLB, when a real TLB miss occurs, the second level TLB (traditional page table,
IPT, or whatever) is consulted, if a miss occurs here, the fault handler is
called).  Management of an MMU is performed by a single module via a
machine-independent interface.  To date, Mach has been ported to Vax, RT/PC,
Sun-3, and NS32032 (Encore Multimax and Sequent Balance 21000 both with
32032 MMU conterpart).  Those are the machines I can talk about, it's been
ported to others as well.  To accomodate these ports, exactly 3 lines of
machine independent code was modified:

	o  The RT/PC compiler had a bug autoincrementing bit-fields, 2 lines
	   of code were rewritten to not autoincrement. [ I just love
	   debugging a virtual memory system using a buggy compiler :-)]

	o  On the Multimax, the console prints out diagnostic information
	   at a point in the boot sequence where the VM implementation was
	   also printing out some computed virtual memory parameters.  The
	   output ended up garbled, so we deleted the printf (1 line of
	   code).

Now, back to the main point... since Mach treats an MMU as a TLB it becomes
possible to start doing interesting things.  For example, I just wrote a
program that sparsely used 256 megabytes of VM and ran it on my MicroVAX
which has only 6 megabytes of physical memory.  [Try *that* on Unix].  The
reason this is no problem is that since the VAX page tables are just a cache
of virtual to physical mappings ... the module that manages the VAX page
tables simply throws away mappings at will.  In fact, the way we have
implemented it is to allocate a fixed pool of "page table memory" which is
managed in an LRU-like fashion (typically there is always enough available
so that we never need to reclaim these pages though).  When a page needs to
be mapped, and there is no corresponding "page table page" in the page table
we just allocate one from the page table memory pool.  Since the only
information to even go into a page table entry is a mapping (which can be
recomputed by the fault handler), we can through away (reclaim) these
mappings at will.

	Avie