Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site anasazi.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!gatech!seismo!hao!noao!terak!mot!anasazi!john
From: john@anasazi.UUCP (John Moore)
Newsgroups: net.arch
Subject: Re: Why Virtual Memory
Message-ID: <375@anasazi.UUCP>
Date: Wed, 20-Nov-85 11:07:20 EST
Article-I.D.: anasazi.375
Posted: Wed Nov 20 11:07:20 1985
Date-Received: Mon, 25-Nov-85 06:55:19 EST
References: <480@seismo.CSS.GOV> <384@unc.unc.UUCP> <6086@utzoo.UUCP> <240@l5.uucp> <483@unc.unc.UUCP> <33540@lanl.ARPA>
Reply-To: john@anasazi.UUCP (John Moore)
Organization: Anasazi, Phoenix Az.
Lines: 48

In article <33540@lanl.ARPA> jlg@lanl.ARPA writes:
>Someone made the point that paging causes a gradual degradation in
>performance for a code that couldn't fit in memory.  On modern machines
>this degradation would not be so gradual.  On a Cray, for example, the
	It depends on what you mean by a modern machine and what you are
using it for. If your Cray, or whatever, is doing timesharing, the virtual
memory may mean the difference between being able to run 5 users (or whatever)
quickly, 20 users with adequate response (by paging) or 20 users with 
intolerable response (if you are forced to SWAP entire jobs in order
to let others run). Also, if the objective is to get maximum utilization
out of an expensive machine, you do that by keeping the processor AND
other devices busy, allowing you to do more total work. Imagine your
machine with two large jobs in it - the sum of which slightly exceed
the memory requirement, and which do some I/O (not purely CPU bound). Without
VM, you would probably just run one of them, as you would waste a lot
of time swapping one in and out. While that one job is running, it is
(for most programming languages) either doing I/O or processing, but not
both. With both jobs running, the CPU is busy close to 100% of the time
doing something useful, because the I/O is in parallel with the
processing. This assumes, of course, that you don't use too small
a working set which would result in unaccpetable paging thrashing.
	Another value of virtual memory (or at least page mapping hardware)
is that it allows a system running multiple jobs which are constantly
coming and going and changing size to do so without swapping or memory
reorganization. If you need 40K and you don't have that much contiguous
memory, who cares -- just map 40K of pages from wherever you find them
into a contiguous address space.
	Continuing with the possible uses of page mapping... In my business
we work very heavily with communicating processes - for data communications
and transaction processing. A lot of overhead can be saved in interprocess
communications by remapping a page with a message in it from one process
to another. The alternatives are to either have the operating system
copy the message (ugh) or to let all such processes access all of memory
(frightening, huh?). Likewise, common pure procedure segments can be
shared, and dynamically attached and released.
	So.... For my dream machine, give me page mapping hardware (with
VM capability - dirty bits, page faults, and the like). Then give me so
much memory that I almost never take a page fault. Finally (the hardest
part) give me an operating system with the smarts to use all of thise
properly.


-- 
John Moore (NJ7E/XE1HDO)
{decvax|ihnp4|hao}!noao!terak!anasazi!john
{hao!noao|decvax|ihnp4|seismo}!terak!anasazi!john
(602) 952-8205 (day or evening)
5302 E. Lafayette Blvd, Phoenix, Az, 85018 (home address)