Subject: Re: Real vfork() (was: third results)
To: Stefan Grefen <grefen@hprc.tandem.com>
From: Eduardo E. Horvath <eeh@one-o.com>
List: tech-kern
Date: 04/15/1998 09:29:35
One important issue all of the COW proponents are ignoring is swap space
overcommit.  This issue was hashed out in comp.unix.internals a few months
ago.  If you have a large process which wants to do a fork()+exec(), you
need to allocate enough swap space to hold a second copy of the process to
be certain you do not overcommit your swap space, even if the child
process will immediately exec() a tiny little executable.  If you don't
have enough swap space to hold the new copy, you can fail the fork() or
overcommit your swap space.  If you overcommit, and the child process
never does an exec() you will eventually be forced to chose whether to
kill a random process, hang the system, or panic.  

Since vfork() does not get its own address space, no swap needs to be
allocated until the exec().  This means your if your 60MB web browser
process uses vfork() you do not need another 60MB of available swap space
to fire off sendmail and deliver the annoying HTML-enhanced email you were
just composing :)  Or find init or inetd or named spontaneously killed
off for no apparent reason.

A forkexec() or spawn() solves the VM overcommit problem, but it becomes
much more complex if any file-descriptor fiddling or other special 
operations need to be done before the exec.

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me