In message <Pine.GSO.3.95.980415085941.29297A-100000@jericho>  "Eduardo E. Horvath" wrote:
> 
> 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.  

But this problem is not limited to [v]fork, it happens with fork and no execs
too. This is general problem what you do in those cases. 
I would vote for tunable policy to either allocate the swap-space (whats
60MB disk these days) or overcommit which and eitther hanging or killing
a process if it fails,  but this is not the point in this discussion.
Especialy since vfork blocks the parent, the live of the child will be 
very short, so the swap-space and the overcommit problem shouldn't be an
important factor for overall system-performance.
Eg. I wouldn't expect more than one vfork outstanding (it will happen 
but only on very rare circumstances). There is no reason to cheat on vfork 
and not doing an exec (you only hurt the parent process) but there 
are reasons to cheat on the shared-address space and create unportable
programs.

I think vfork has its use in telling the OS to exepect an exec so it can
conserve resources (mostly by stalling the parent until the child exits or
exes), but it shouldn't share the address space, even if it costs performance.
Like the speed gain, having vfork share the address space of the parent is a 
kludge for another problem.
The question is wether the problem this kludge creates is worth the gain
(this question was easy to answer for non-paging systems).

Swap-space is cheap these days as is CPU horse power. Whats getting more
and more expensive is hours working on porting programs that expect
sharing or non-sharing vforks() to systems with/without them.

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

AIX has a workaround for that, so that the random kills won't effect important
processes, this is the 2'nd best way to handle it (after allocating the 
swap space, but I may be biased here ....). 

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

Yes and it is not portable. I think we shouldn't go he M$ way and
make the API a moving target just because we think we can get a 
(small) performance gain by having a special system call for every case.

Stefan

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

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
 --- Hacking's just another word for nothing left to kludge. ---