Newsgroups: comp.unix.wizards
Path: utzoo!utgpu!dennis
From: dennis@gpu.utcs.utoronto.ca (Dennis Ferguson)
Subject: Re: BSD virtual memory mngmt algorithm. Was: Performance Tuning Ultrix 4.1
Message-ID: <1991May11.224343.19845@gpu.utcs.utoronto.ca>
Keywords: paging swapping fast large load BSD
Organization: none at all
References: <1991Apr30.160331.16215@milton.u.washington.edu> <1991May7.065338.1027@ubeaut.enet.dec.com> <16121@smoke.brl.mil> <13087@dog.ee.lbl.gov>
Date: Sat, 11 May 1991 22:43:43 GMT

In article <13087@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes:
>In article <16121@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>>Other than Sun, almost all ports of 4.nBSD have had to overhaul the
>>virtual memory code, which was written quite narrowly for a VAX-like
>>VM system.  (Sun simply BUILT a VAX-like VM system!)
>
>Well no: while the old VM was rather icky and somewhat painful to
>modify for 3-level schemes such as the i386 and 68030, it did work
>pretty well for anything that had hardware PTEs.
>
>Sun did not build a VAX-like VM system, if by `system' you mean `MMU';
>the Sun MMU is much more like a TLB.  What they did, rather, was make
>software PTEs that simulated a VAX.

The IBM RT, with its inverted page tables, was another one for which
the port of 4.x BSD was done by implementing VAX-like PTEs in software.
As efficient text sharing had to be implemented by moving the data up
into a different (256 Mb) segment from the text, the macros for converting
from VAX-style PTEs, where the data PTEs are contiguous with text, to
memory addresses and back became extremely ugly.

While functional, the end result was pretty disgusting.

>The current BSD development systems have a Mach-based VM (with a few,
>ah, `interesting' bugs) which is scheduled to change rather a lot over
>the next few months....

One merit of the old BSD VM with respect to the RT (if lack of function
can be called a "merit") is that it didn't try to do anything fancy.
Inverted page tables really suck for implementing things like copy-on-write
forks, and are pretty awful for sharing memory in general unless you can
arrange it so that shared objects are usually kept segment-aligned.  The
RT (and the RS/6000, which inherited the same memory management) probably
makes a pretty good test case for the generality of a "portable" VM subsystem
since its MMU is quite unconventional.

Dennis Ferguson
University of Toronto