Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!ames!sun-barr!ccut!titcca!cc.titech.ac.jp!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.arch
Subject: Re: Paging page tables
Message-ID: <5796@titcce.cc.titech.ac.jp>
Date: 6 Jul 90 07:58:45 GMT
References: <3300142@m.cs.uiuc.edu> <9758@pt.cs.cmu.edu> <PCG.90Jun30230310@odin.cs.aber.ac.uk> <58001@bbn.BBN.COM>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 23

In article <58001@bbn.BBN.COM>
	lkaplan@BBN.COM (Larry Kaplan) writes:

>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().

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