Berkeley paging
Chris Torek
chris at mimsy.UUCP
Sat May 14 08:13:24 AEST 1988
In article <7878 at brl-smoke.ARPA> gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
>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.)
As others have mentioned, the claim about Sun's MMU is nonsense. It is
true that the 4BSD paging code is overly Vax-oriented: it assumes such
things as page table entries and two-level mappings. Other than that,
there is nothing inherently wrong with Berkeley's `clock' pageout
scheduler, which is usually what critics claim makes VMS superiour.
Indeed, it can be argued that the clock scheme is more `Unix-like' than
the working set scheme; on the average, it will give better total
machine throughput (this is intuitively obvious to me and I intend not
to thrash the subject to death here: that has been done before), though
its affect on any individual process is not easily predictable---the
clock scheme, which is basically `if the machine is getting short of
space, kick out any deadwood', depends on how hard the machine is being
pushed, while the working set algorithm is more or less `if the process
is over its quota, whittle it down by kicking out its deadwood'. The
chief disadvantage of the global algorithm is that administrators
cannot easily allocate real memory to any given process.
(When you get right down to it, VMS is not strictly working set
either. Paging *entirely* by working set quotas is stupid, and VMS
is not stupid. [Just darned annoying :-) ])
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris at mimsy.umd.edu Path: uunet!mimsy!chris
More information about the Comp.unix.wizards
mailing list