Path: utzoo!attcan!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: When did paging get into System V
Message-ID: <7886@brl-smoke.ARPA>
Date: 13 May 88 20:40:01 GMT
References: <53@lazlo.UUCP> <142700033@occrsh.ATT.COM> <651@pyuxe.UUCP> <7878@brl-smoke.ARPA> <53104@sun.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 57

In article <53104@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes:
>> So?  Performance tests showed no significant performance advantage of
>> demand paging over the then-current UNIX System V scheme of partial
>> swapping.
>Umm, I don't even think System V had been *released* when the original paging
>BSD releases came out.

Nor did I claim this.

>I believe one of the papers on the BSD paging code
>indicated that there *was* a performance benefit over the 32V partial swapping
>scheme for large jobs.

And the AT&T study also showed that for certain types of jobs there could
be a measurable improvement.  However, there wasn't one for the normal USG
UNIX job mix.

>  It was not until the additional advantages of an organized
>> scheme like the UNIX System V region-oriented approach became apparent
>> (e.g. shared libraries) that there was reason enough to implement it.
>The first paging S5 releases didn't have shared libraries; that arrived later.
>Are you certain that the organizational advantages of a less *ad hoc* scheme
>were the *only* reasons they went to paging?  I doubt that.

Again, you're trying to refute things I didn't say.
My conversations years ago with people like Larry Brown led me to
conclude that they indeed were more swayed by such considerations
than by "performance" arguments.  AT&T's announced goal of the
paging version to to have NO WORSE performance than the partial
swapping version.  (The emphasis was theirs.)

>> Conversations I've had with kernel implementors indicate that, modulo
>> a few glitches that can be readily corrected, the UNIX System V scheme
>> (which resembles VMS's) is on the right track, and that Babaoglu's
>> scheme embedded in 4BSD often has to be totally replaced.  (Sun
>> designed their original memory management hardware to look virtually
>> the same as the VAX's, to avoid this.  Not everyone has had that option.)
>This is, as somebody pointed out, complete nonsense.  The Sun MMU looks nothing
>like the VAX MMU; the pre-4.0 VM implementation has code to sort of emulate the
>VAX MMU on a Sun.

Okay, if that is the case then it still supports the point I was making,
which is that the 4BSD virtual memory scheme was quite heavily tied to
the VAX design.  Apparently the Sun(-1) MMU provided enough hooks for a
VAX emulation to work, but other vendors of super-mini class machines
have not always found this to be the case for their MMUs (at least not
without unacceptable performance penalties, e.g. overly-large reference-
bit tables).

DMR mentioned to me not too long ago that the Bell Labs research folks
had also thought that replacing the 4BSD memory management scheme in
their system (which evolved from an early Berkeley VAX release) would
be worth doing, just that they hadn't found the time.

Perhaps SunOS 4.0 VM is a lot better; it's hard to tell from here.
Without regions, how do you keep track of user-attached segments of
memory?  By long lists of pages (bit maps)?