Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84; site opus.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!hao!nbires!opus!rcd
From: rcd@opus.UUCP (Dick Dunn)
Newsgroups: net.arch
Subject: Re: Page size and the meaning of life
Message-ID: <146@opus.UUCP>
Date: Wed, 23-Oct-85 00:16:41 EDT
Article-I.D.: opus.146
Posted: Wed Oct 23 00:16:41 1985
Date-Received: Fri, 25-Oct-85 07:19:52 EDT
References: <926@decwrl.UUCP> <931@lll-crg.ARpA>
Organization: NBI,Inc, Boulder CO
Lines: 50

> Would anyone care to comment on why we need virtual memory at all
> with a 256 meg real memory being available in the near future?

First response:  How near?  1 Mbit chips are real but not quite big-time
commercial stuff yet (that means: not CHEAP yet), but suppose that they
are.  256 Mb = 256*8 = 2K of these chips, which is a fair space-heater in
any technology.  In larger machines, maybe yes; we're a few years away in
small machines.

Second response:  VM is a means for getting more use out of the memory
you've got.  Until that 256 Mb is almost free, there's a cost tradeoff to
be considered for how much memory you put in.  VM sets the "hard limit" of
a process address space independently of the actual physical memory on the
machine, so you don't have to go out and buy more memory to run a program
with a large address space--it just runs slower.  (Yes, in some cases it
runs intolerably slower.  If that happens, go buy more memory, obviously.)

Third response:  Decrease program startup?  (Tentative.)  If you insist on
everything being in physical memory, you gotta load the whole program
before you start execution.  Might take a long time--the case of interest
is where a program has gobs of seldom-used code.  The counter to this
response is that if a program has poor locality of reference--which is
common during startup!--the VM paging behavior is essentially to load a
large part of the program but in random order, which can make it take
longer than loading all of it sequentially.

Fourth response:  Maybe VM is appropriate to a certain balance of process
size, memory cost and size, and backing store cost/speed.  You could argue
that larger machines are now outside the domain of that particular set of
tradeoffs.  Smaller machines are not.

> I haven't seen a virtual memory system yet that would stand up
> to one of my simulation programs when the program size exceeded
> the physical memory size.  As soon as the system started paging
> the performance was so out to lunch that you would have to wait
> days for the program to complete and everyone would be on your
> back for sending the machine to lunch...

This is a lesson that strong advocates of virtual memory seem to have to
keep learning (or rather, that we have to keep pounding at them):  There
are programs which should NOT be run as pageable.  The whole idea of paged
virtual memory is based on the assumption that you can keep the "working
set" of the process(es) of interest in physical memory.  Some processes
have very large working sets--or more correctly, they don't obey the
working-set model.  These need different treatment.  It bears repeating
occasionally that thrashing can happen with a single process (as illus-
trated above); it doesn't have to come from process interactions.
-- 
Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
   ...Simpler is better.