Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!emory!mephisto!bbn.com!lkaplan
From: lkaplan@bbn.com (Larry Kaplan)
Newsgroups: comp.arch
Subject: Re: Paging page tables
Message-ID: <58014@bbn.BBN.COM>
Date: 6 Jul 90 13:49:42 GMT
References: <3300142@m.cs.uiuc.edu> <9758@pt.cs.cmu.edu> <PCG.90Jun30230310@odin.cs.aber.ac.uk> <58001@bbn.BBN.COM> <5796@titcce.cc.titech.ac.jp>
Sender: news@bbn.com
Reply-To: lkaplan@BBN.COM (Larry Kaplan)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 41

I wrote:
>
>>Wrong virtual model?  This sounds like a religious comment.  My understanding
>>is that UNIX has wanted to have true copy-on-write semantics for a while but
>>just never got around to it.  Witness the vfork() hack in BSD which was
>>suppose to disappear when "proper sharing semantics" were implemented.
>>The system we build has MACH ancestry (though a totally rewritten VM system)
>>and therefore allowed us to make vfork() the same as fork().

In article <5796@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>
>If you implement vfork() the same as fork(), your system is broken.
>
>If a large process want to fork(), it requires a large amount of virtual
>memory space (twice the size of the process). So, if the process almost
>used up virtual memory space, the process can not fork(). Copy-on-write
>won't help.
>
>If a large process want to vfork(), no extra virtual memory space
>is necessary.
>
>This is a serious problem when large scale computing is necessary.
>
>						Masataka Ohta

This shows some serious misunderstanding on your part.  The idea behind 
copy-on-write is that a proper fork() requires NO EXTRA physical memory for 
the child process (except that required for kernel data structures and page 
tables).  You probably end up needing one stack page pretty soon.  Virtual 
memory is VIRTUAL.  Who cares if you were running out in one process?  You get 
an entire new address space in the next.  This implementation of fork() is
what fork() was always intended to be, as far as I can tell.  By doing fork()
correctly, the need for a separate vfork() disappears (as stated in the BSD
man pages).

#include <std_disclaimer>
_______________________________________________________________________________
				 ____ \ / ____
Laurence S. Kaplan		|    \ 0 /    |		BBN Advanced Computers
lkaplan@bbn.com			 \____|||____/		10 Fawcett St.
(617) 873-2431			  /__/ | \__\		Cambridge, MA  02238