Re: [BUG] oom killer not triggering in 2.6.9-rc3

Andries Brouwer
2004-10-12T09:46:46Z

On Mon, Oct 11, 2004 at 11:03:16PM -0600, Chris Friesen wrote:

> Alan Cox wrote:
> >The OOM killer is a heuristic.
>
> Sure, but presumably it's a bad thing for a user with no priorities to be
> able to lock up a machine by running two tasks? I'm not complaining that
> its killing the wrong thing, I'm complaining that the machine locked up.
>
> > Switch the machine to strict accounting
> >and it'll kill or block memory access correctly.
>
> I must be able to run an app that uses over 90% of system memory, and calls
> fork(). I was under the impression this made strict accounting unfeasable?
>
> Chris

No.

The default allows a job to take ten times what is available,
and bad things happen later.
With overcommit mode 2 there is an upper bound, but you can
twiddle the bound as desired. From proc(5):

/proc/sys/vm/overcommit_memory
This file contains the kernel virtual memory
accounting mode. Values are:
0: heuristic overcommit (this is the default)
1: always overcommit, never check
2: always check, never overcommit
In mode 0, calls of mmap(2) with MAP_NORESERVE set
are not checked, and the default check is very
weak, leading to the risk of getting a process
"OOM-killed". Under Linux 2.4 any nonzero value
implies mode 1. In mode 2 (available since Linux
2.6), the total virtual address space on the system
is limited to (SS + RAM*(r/100)), where SS is the
size of the swap space, and RAM is the size of the
physical memory, and r is the contents of the file
/proc/sys/vm/overcommit_ratio.

/proc/sys/vm/overcommit_ratio
See the description of /proc/sys/vm/overcommit_mem

So, what you have is a bound on virtual memory, and that bound
can very easily be larger than twice physical memory.

Andries