On Tue, 14 Apr 1998 19:52:24 +0200 
 Stefan Grefen <grefen@hprc.tandem.com> wrote:

 > I think all effort should be directed to making fork()'s COW cheaper so that
 > the remaing benefit of vfork is that it blocks the parent until the 

A good amount of effort was directed at making COW better in UVM.  And
an address space-sharing vfork() _still_ turned out to be a win.  It shaves
several seconds off a build of libc on my 200MHz PPro.

I really don't understand why we're arguing about this.  It seems obvious to
me that, in the cases where it was originally meant to be used, it is a
performance win, and really nothing else is going to be faster.

Let's look at what happens when you vfork/exec using the 4.4BSD vfork
and COW:

	- Traverse parent's vm_map, marking the writable portions of the
	  address space COW.  This means invoking the pmap, modifying PTEs,
	  and flushing the TLB.

	- Create a vm_map for the child, copy the parent's vm_map entries
	  into the child's vm_map.  Optionally, invoke the pmap to copy
	  PTEs from the parent's page tables into the child's page tables.

	- Block parent.

	- Child runs.  If PTEs were _not_ copied, take page fault to get
	  a physical mapping for the text page at the current program counter.

	- Child execs, and unmaps the entire address space that was just
	  created, and creates a new one.  This implies that the parent's
	  vm_map has to be traversed to mark the COW portions not-COW.

	- Unblock parent.

	- Parent runs, takes page fault when modifying previously R/W
	  data that was marked R/O for COW (no data is copied at this
	  time

...and now the 3.0BSD/NetBSD vfork, using address space sharing:

	- Take reference to parent's vmspace structure.

	- Block parent.

	- Child runs.  No page faults occur because the parent's page
	  tables are being used, and the PTEs are already valid.

	- Child execs, deletes the reference it had to the parent's,
	  and creates a new one.

	- Unblock parent.

	- Parent runs.  (No page faults occur because the parent's
	  vm_map was not modified.)

So, in the case where you're going to fork and then exec, which is going
to be faster?  Clearly the one that has to do less work.  Even if your
COW algorithms are good, you still have to do a lot more work compared
to the vmspace-sharing case!

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939