Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amdcad!sun!whitsun!pugs
From: pugs%whitsun@Sun.COM (Tom Lyon)
Newsgroups: comp.unix.wizards
Subject: Re: Papers on Layered UNIX systems like Apollo VRM, Apollo SR10, etc.
Summary: UTS tricks under VM
Message-ID: <71495@sun.uucp>
Date: 4 Oct 88 17:00:15 GMT
References: <7376@rpp386.Dallas.TX.US> <5694@killer.DALLAS.TX.US> <bcHsHc5qnd1010RzzbI@amdahl.uts.amdahl.com>
Sender: news@sun.uucp
Distribution: na
Lines: 20

In article <bcHsHc5qnd1010RzzbI@amdahl.uts.amdahl.com>, craig@amdahl.uts.amdahl.com (Craig Harmer) writes:
> Sorry, i don't think we've written any papers on the subject of running
> under VM.  There's really not alot to say, aside from paying attention to
> all the idiosyncracies of whatever VM you're running under, in order to
> get decent performance.  It's particularly hard to get decent performance
> using virtual memory as a "Virtual Operating System".

Actually, I wrote a paper at Amdahl 9 years ago, when UTS was still called "Au",called "How to get the Pb out of Au".  The single thing which increased 
performance most under VM was to make the kernel run with interrupts disabled
except in "sleep", so that all the calls to spl() could be removed! The calls
to spl() required traps to VM to implement them, so the ran several orders of
magnitude slower in a virtual machine than on a real machine.  Lest anyone
think this is a terrible idea, it turns out that CP (the VM kernel) does
exactly the same thing.  IBM I/O devices are built for high latency.

The other neat thing under VM was virtual page faults; VM would notify the
kernel when a user process took a page fault so the UNIX kernel could schedule
some other process; another notification would arrive after VM got the page
in.  This level of page faulting was independent of the paging eventually
implemented by the UTS kernel.