🚀 go-pugleaf

In article <5875@orca.wv.tek.com> andrew@frip.WV.TEK.COM
(Andrew Klossner) writes:
>... you have to build a duplicate set of page tables in order to
>implement copy-on-write, but for processes that aren't huge, this isn't
>a large part of fork() handling.  The kernel has to do a lot of other
>work besides just building the PTEs.  For huge processes, though, we've
>observed that PTE creation time dominates fork() time.

This is useful information.  It does, however, make some assumptions:

1. PTEs.  Not all machines with virtual memory require PTEs (e.g.,
   all MIPS-based machines: page translation is done in software).

2. PTEs (if present) must be copied.  One valid approach, possible
   on some (particularly two level page table) machines, is to mark
   the primary pages invalid or unwritable.  Since most uses of fork
   are of the form:

	switch (pid = fork()) {
	case 0:
		diddle this, that, and the other thing;
		execv(name, argv);
		error(notfound);
		_exit(1);
		/* NOTREACHED */

	case -1:
		error(cannotfork);
		break;

	default:
		record(pid);
		break;
	}

   the kernel could:
	a. suspend execution of the parent
	b. hand PTEs to the child, mark them `must not be written'
	   or `invalid'
	c. start a timer to allow resumption of the parent
	d. let the child run.  When it gets page faults, make copies
	   of exactly those PTEs and pages needed to let it continue.
	   When it exits or execs, cancel the timer, and move the PTEs
	   back, replacing those that were copied with the originals
	e. if the timer expires, suspend the child, copy the PTEs back
	   to the parent (replacing modified PTEs and pages with
	   originals), and then resume both processes.

   This is a fair amount of work (particularly in data structures for
   tracking original and copied PTEs) and may well not be worth the
   effort---but it might turn out to help tremendously.  The kernel
   could choose whether to use this trick based on process size.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris