Re: [9fans] Virtual memory in BSD and Plan9

["John S. Dyson" <dyson@iquest.net>]

wkj-despam@eecs.harvard.edu (William Josephson) wrote in message news:<20011025142927.B8085@honk.eecs.harvard.edu>...
> On Thu, Oct 25, 2001 at 01:55:25PM -0400, Russ Cox wrote:
> > The discussions here were talking about many-years-old
> > systems.  I don't think anyone even mentioned Plan 9's VM system,
> > which is just about the simplest thing you could imagine.
> > The BSDs have oodles more ``features.''  I'd look in
> > www.researchindex.com for the latest stuff, and in McKusick et al.
> > (Design and Implementation of the 4.4BSD OS) for older stuff.
> > You can decide for yourself whether Plan 9 needs any of it.
> 
> You probably want to take a look at Charles Cranor's PHd thesis from
> Washington on UVM.  If I recall correctly, some of the *BSDs (NetBSD,
> FreeBSD?) have picked it up or at least borrowed ideas.
> 
FreeBSD and NetBSD have different VM systems.  FreeBSD's (which I
am the primary implementer), is really a corrected and filled out
MACH VM for UNIX.  It provides lots of the necessary shortcuts
fully virtualized for the process VM forking and things like that.
The original MACH VM port really wasn't meant as being production
ready (per my discussions with Hibler), but was more of a feasibility
exercise.  Even though it wasn't fully made robust in the original
implementations, it wasn't that much worse than many commercial UNIX
VM behaviors.

Probably the biggest difference doesn't occur during 'normal'
memory resident situations, but where FreeBSD has rather advanced
paging stats, and really does put off the thrashfest until the
system doesn't have enough pages to supply an adequate resident
working set.  If there is minimally enough memory, FreeBSD will
converge reasonably quickly, without undue thrashing.  In my early
experiments, it was very satisfying to hear the system 'calm down'
after experiencing thrashing due to a necessary change in working
set population.  Most other systems tended to keep on thrashing
for long periods, even when there was obviously enough memory.  The
pseudo-random pagouts and invalidations from non-FreeBSD systems
tended to really screw up the page reference information on memory
segments being used by otherwise runnable processes.   The relatively
good behavior has been especially useful when running user-mode
windowing systems, where the blocking from poorly chosen page
invalidations can really stop-up the works.

Both FreeBSD's VM and NetBSD's VM work pretty well (no real complaints
from either party), and most/all of the limitations of the original
MACH VM have been expunged.  There were even cases of limitations
that I thought to be unsolvable in the FreeBSD code eventually simply
be an 'exercise in data structures', and the last REAL limitation
due to address space/fork inheritance was remedied as a result of
competition from NetBSD's new VM stuff.

FreeBSDs and NetBSDs code is both adequately portable, and that
should not be a deciding issue.  Frankly, the most important deciding
issue is probably based upon knowledge of the VM code that the
individual who might do the port to Plan 9.  One might make a
'decision' that the VM shouldn't page anyway (except in odd situations),
and so the relative advantages of the two systems becomes less
important.

My philosophy is based upon the fact that an OS MUST NOT just be a fair
weather friend, and from my rather VM-centered viewpoint, I believe that
this includes the fact that VM shouldn't randomly thrash, when it could
more actively converge to a reasonable working set (when possible.)

If starting from scratch, it is really easy to write some code that
works.   However, there is ALOT more work to making a VM system
function under load to maximize availability of CPU cycles.  Unfortunately,
it is clear that VM system behavior is almost always a secondary
priority, because it doesn't specify/benchmark very easily.

John