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

Bernd Walter ticso at cicely7.cicely.de
Thu May 21 19:37:12 UTC 2009

On Thu, May 21, 2009 at 10:52:26AM -0700, 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.
> Are there any other than fork (and mmap/sbrk) situations that would 
> overcommit?

If your system has enough virtual memory for working without overcommitment
it will run fine with overcommitment as well.
If you don't have enough memory it can do much more with overcommitment.
A simple apache process needing 1G and serving 1000 Clients would need
1TB swap without ever touching it.
Same for small embedded systems with limited swap.
So the requirement of overcomittment is not just a requirement of old days.
Overcomittment is even used more and more.
An example are snapshots, which are popular these days can lead to
space failure in case you rewrite a file with new data without growing
its length.
The old sparse file concept is also one of them, which can confuse
unaware software.
And then we have geom_virstore since a while.
Many modern databases do it as well.

B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

More information about the freebsd-hackers mailing list