Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!amdcad!light!bvs
From: bvs@light.uucp (Bakul Shah)
Newsgroups: comp.arch
Subject: Re: HP-PA and MPE XL
Message-ID: <1990Feb26.184759.9448@light.uucp>
Date: 26 Feb 90 18:47:57 GMT
References: <37774@cornell.UUCP>
Reply-To: bvs@light.UUCP (Bakul Shah)
Organization: Bit Blocks, Inc.
Lines: 68

In article <37774@cornell.UUCP> huff@cs.cornell.edu (Richard Huff) writes:
>       ...
>I would assert that with the large address space of HP-PA, software 
>would NOT need address aliasing (aside from the fact that HP-PA 
>explicitly does not allow 2 distinct 64 bit virtual addresses to point 
>to the same physical address).  Can anyone name a use for aliasing that 
>wasn't originally designed to get around the problems and/or limitations 
>of:
>
>   a)  small 32-bit virtual address spaces that were logically disjoint 
>       between processes, or
>
>   b)  the TLB/cache flush/reload penalty that (conventional) multilevel 
>       page tables exact in the presence of rapid context switching 
>       between zillions of processes
>
>Can anyone name a use for copy-on-write that wasn't designed to fix one 
>of the above two problems (or to support the brain dead policies of 
>fork(), as mentioned above) ?

Aliasing is needed if you want to map a segment at more than one
virtual address (either in the same space or different ones).  A
small 32-bit virtual address space is *not* the reason for doing
so.  For instance, I may want to access the same segment as
readonly as well as read/write from the same address space.  Not
allowing multiple virt. address to point to the same phys page
also disallows copy-on-write.

Copy-on-write is not used to solve a) or b) above.  It is merely
an optimization, albeit a very useful one.  It has two benefits in
cases where atleast page size data gets copied but majority of
such data is never touched again:

	a) time efficiency: overhead for implementing COW is a lot
	   less than copying everything.  Only subsequently
	   changed pages are copied.

	b) space efficiency: overhead for maintaining COW data
	   structures is a lot less than allocating pages for
	   copied data.  Only subsequently changed pages are
	   allocated real pages.

Fork() happens to fall in this category but it isn't the only one.
Other examples are read(), shared libraries, debugging a shared-
text program, IPC where you pass lotsa data, atleast one way of
doing nested transactions, etc.

It is a generic lazy evaluation technique, not just limited to
virtual memory accesses (or if you prefer, excesses :-).  COW is
what you need for building (slowly changing) filesystem/database
on WORM devices.  The editor I use does a COW of an entire file if
I change it (breaks its link).  Allows me to maintain multiple
source trees without maintaining a zillion copies of identical
files.  The paradigm here is to share everything but make a
private copy if you change something.

>Can anyone name another virtual memory scheme that can support a large 
>sparse address space as efficiently as the inverted page table approach 
>that I have outlined above?  (Where "large address space" means at least 
>48 bits, and "efficiently" refers to the size of the data structures, 
>especially with regard to memory resident data structures.)

You may want to read up about Mach.  It seems to handle large
sparse address spaces just fine for a large variety of hardware
page mapping structures.

-- Bakul Shah
   ..!{ames,sun,ucbvax,uunet}!amdcad!light!bvs