Re: What to do when out of memory

[John Ripley]

Andreas Bombe wrote:
> 
> On Sat, Jan 22, 2000 at 04:13:33AM +0000, Aaron Lehmann wrote:
> > The basic problem is that if I run a program that eats up all the memory
> > on the system than the kernel will start swapping crazilly and make the
> > system completely unresponsive.
> [...]
> > I know that your first impulse will be to tell me to set PAM's limits.conf
> > or a limits option within my shell. I think this is irrelevant. Regardless
> > of userspace settings, the kernel should handle OOM situations more
> > gracefully than swapping to death. This may be a gross oversimplification
> > of the problem (as I have no kernel hacking experience or knowledge), but
> > can't the kernel just deny memory allocations if all the memory on the
> > system is in use?
> 
> 2.2 and later don't allocate more memory to user space than is
> available unless overcommit_memory is explicitly set.  And if you don't
> want the kernel to swap when memory gets tight then don't add a swap
> partition/file in the first place, easy.

Actually, Linux will allow to you allocate almost infinite amounts of
memory, so long as you only allocate it in chunks smaller than
physical+swap:

- If you're on a machine with swap, when you get round to using it (or
use mlockall) things swap like mad and eventually block (or hard lock,
which my 2.3.39 machine does).

- On a machine without swap, when you get round to using it, it'll
SIGBUS. Or another random process that schedules will SIGBUS as its
libraries or executable gets page faulted, and can't page.

In neither case did mmap or brk return ENOMEM. The only notification the
process got of running out of memory was being killed.

It seems it is possible to keep track of memory such that any successful
mmap will always be pageable - keep track of allocated pages which are
pending paging and subtract that from free_pages in vm_enough_memory().
Still, this is getting back to a short thread I started long ago - if I
have some spare time I'll try implementing it.

-- 
John Ripley, empeg Ltd.
http://www.empeg.com