Why kernel kills processes that run out of memory instead of just failing memory allocation system calls?

[Daniel O'Connor]

On Fri, 22 May 2009, Yuri wrote:
> Nate Eldredge wrote:
> > Suppose we run this program on a machine with just over 1 GB of
> > memory. The fork() should give the child a private "copy" of the 1
> > GB buffer, by setting it to copy-on-write.  In principle, after the
> > fork(), the child might want to rewrite the buffer, which would
> > require an additional 1GB to be available for the child's copy.  So
> > under a conservative allocation policy, the kernel would have to
> > reserve that extra 1 GB at the time of the fork(). Since it can't
> > do that on our hypothetical 1+ GB machine, the fork() must fail,
> > and the program won't work.
>
> I don't have strong opinion for or against "memory overcommit". But I
> can imagine one could argue that fork with intent of exec is a faulty
> scenario that is a relict from the past. It can be replaced by some
> atomic method that would spawn the child without ovecommitting.

If all you are going to do is call execve() then use vfork().

That explicitly does not copy the parent's address space.

Also your example is odd, if you have a program using 1Gb (RAM + swap) 
and you want to start another (in any way) then that is going to be 
impossible.

If you had a 750Mb process that forked and the child only modified 250Mb 
you'd be all right because the other pages would be copies.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090522/2271fe8f/attachment.pgp