Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!sdcsvax!ncr-sd!greg
From: greg@ncr-sd.SanDiego.NCR.COM (Greg Noel)
Newsgroups: comp.sys.amiga
Subject: Re: Argument for Virtual Memory
Message-ID: <1912@ncr-sd.SanDiego.NCR.COM>
Date: Mon, 23-Nov-87 22:21:36 EST
Article-I.D.: ncr-sd.1912
Posted: Mon Nov 23 22:21:36 1987
Date-Received: Thu, 26-Nov-87 21:34:04 EST
References: <8711151944.AA25448@cory.Berkeley.EDU> <1089@sugar.UUCP>
Reply-To: greg@ncr-sd.SanDiego.NCR.COM (Greg Noel)
Organization: NCR Corporation, Rancho Bernardo
Lines: 51

In article <1089@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) tries to
distinguish between virtual memory, protected memory, and memory management.
The definitions he uses are basically correct, but he makes one small error:
>Virtual memory is what you have when part of the memory a program uses isn't
>in real RAM, but is copied in from secondary storage on demand. This usually
>requires memory management.

This is a definition for "swapping," and not for virtual memory, although the
two are frequently found in the same system.  A better rule of thumb is that
if the operating system could move a process within real memory without the
process having to be aware of it, then you have virtual memory.  Note that
this doesn't say that it \does/ relocate processes, just that it \could/ if
it wished.  Swapping or paging systems build on top of this the ability to
move pieces of the process between real memory and secondary storage, or to
run a partially unloaded program, but that is not inherent in the meaning of
"virtual memory."

Perhaps an example will make this clear: I once worked on a project that had
a number of real-time tasks with variable storage requirements, so they each
used a (common) free storage management package.  These tasks all had to live
on the same computer.  Some non-techincal idiot had added up the maximum
storage required by each task, and had specified a computer memory only a
little larger than the sum of the three requirements.  The results were
predictible; memory got fragemented and the system would run out of free
memory with about 1/3 of the memory unallocated (Knuth's result).  There
was no way to get the hardware upgraded (it was a military procurement, and
the specifications were cast in concrete), so we had to come up with a way
to not run out of storage.  The thing had an MMU (for use by the background
programs), so we just put the real-time tasks in a virtual name space about
three times as large as the actual space, and made the free storage package
smart about allocating things within pages.  That, and a little tweaking of
the software so that more requests were in page-sized increments, allowed
us to keep running until the memory was 95% to 98% utilized.

(The interesting thing is that the workload is directly applicable to the
Amiga -- we had a relativly few large requests (corresponding to programs
being loaded) and a lot of smaller requests (corresponding to the data
being manipulated).  This means that an Amiga that has been running for a
while will usually run out of memory when it is less than 75% full.  Adding
a MMU to the Amiga would be equivalent to adding 20% to 25% more memory,
not to mention the increased capability that a MMU would give.  I don't
know how much a MMU would cost, but if it is less than one-quarter of the
memory cost, then you get more for your buck by adding adding a MMU.  Note
that the leveraging increases the more memory you have.)

The point of all of this is that here we are pretty clearly using virtual
memory but not doing any paging.  Some of the proposals for a modified
memory model for the Amiga have been similar to this; it's certainly an
idea worth investigating.  I'd certainly like to see it in a future OS
release......
-- 
-- Greg Noel, NCR Rancho Bernardo   Greg.Noel@SanDiego.NCR.COM  or  greg@ncr-sd