Just some optimization regarding your description of the 4.4BSD vfork:

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

There is no need to mark anything COW in the parent's vm_map, since the
parent doesn't access its address space until after the child doesn't use
its copy of the address space anymore.  So:

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

Mark any copied entries that are writable as COW in the copy during this.

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

Now you don't have to traverse the parent's vm_map again, since it wasn't
modified at all.

> 	- 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

Depending on whether the mmu supports multiple address spaces, the parent
will not get any (additional) faults since its ptes weren't modified.

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800