Wandering Thoughts archives

Why vfork() got created (part 1)

The fork() system call presents a problem for strict virtual memory overcommit. 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. 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.