== Why _vfork()_ got created (part 1)

The _fork()_ system call presents a problem for [[strict virtual memory
overcommit MemoryOvercommit]]. Because it duplicates a process's virtual
address space, strictly correct accounting requires that the child
process be instantly charged for however much committed address space the
parent process has; if this puts the system over the commit limit, the
_fork()_ should fail.

At the same time, in practice most _fork()_ child processes don't use
very much of the memory that they're being charged for; almost all the
time they touch only a few pages and then throw everything away by
calling _exec()_.  Failing such a _fork()_ because the strict accounting
says you should is very irritating to people; it is the system using
[[robot logic UnixAnnoyance]]. But at the time of the _fork()_, the
system has no way of telling parsimonious 'good' child processes that
will promptly _exec()_ from child processes that are going to stick
around and do a lot of work and use a lot of their committed address
space.

The answer (I will not call it a solution) is _vfork()_, which is a
_fork()_ that doesn't require the kernel to charge the child process for
any committed address space. This allows large processes to spawn other
programs without running into artificial limits, at the cost of being a
hack itself.

(In order to make this work the child can't actually get any pages of
its own; instead it gets to use the parent's pages, and to make this
work the parent process gets frozen until the child exits or _exec()_s.)

Actually this is a bit of a lie, because it is only half the reason
that _vfork()_ exists. But that's another entry, because this one is
already long enough.