Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site seismo.CSS.GOV
Path: utzoo!watmath!clyde!cbosgd!gatech!seismo!mo
From: mo@seismo.CSS.GOV (Mike O'Dell)
Newsgroups: net.arch
Subject: Why Virtual Memory
Message-ID: <480@seismo.CSS.GOV>
Date: Mon, 21-Oct-85 10:31:41 EDT
Article-I.D.: seismo.480
Posted: Mon Oct 21 10:31:41 1985
Date-Received: Tue, 22-Oct-85 05:34:20 EDT
Organization: Center for Seismic Studies, Arlington, VA
Lines: 30

Why virtual memory when physical memories are getting larger?

Protection and resource allocation.

Mapping two address spaces disjointly is a very easy way to insure
two processes don't get in each other's way.  It also provides a very
clean way to do controlled sharing of memory.

Allocation control for large physical memories is as difficult a task
as ever, and resource allocators which deal with fixed-size pieces
(pages) are simpler and more efficient than those which deal with
varying size pieces.

For these reasons, at least, virtual memory is important in future
architectures, particularly with large physical memories.

Finally, for my money, virtual memory has never been good for providing
"free lunch" - ie, running programs larger than physical memory,
EXCEPT when the size of the program and its reference patterns are
such that memory allocation efficiency becomes a dominant factor.
As the gent from Livermore would admit, his giant Monte-Carlo simulation
probalby doesn't have well-behaved addressing locality, but rather
references all its memory all the time.  Programs like these need
Virtual-to-Real ratios close to 1.  

	TANSTAAFGPVSSA
	-Mike O'Dell

PS - There Ain't No Such Thing As A Fast General-Purpose Variable-Size
Storage Allocator