Over-enthusiastic OOM killer.

Over-enthusiastic OOM killer.

[Dave Jones]

The oom killer just killed a bunch of processes on my workstation.
What I don't understand, is why this was deemed necessary, when
there was 400MB of buffer cache sitting around in memory, and 175MB
of free swap space unused. (66mb of swap was used)
		
Seems something is drastically amiss here.

The box is still alive, if theres anything else I can provide,
although cron.daily just ran 5 minutes after the oomkill,
which has polluted the situation a little..

It's been up for just over 10 days on pre2.

regards,
Dave.

-- 
| Dave Jones.                    http://www.codemonkey.org.uk
| SuSE Labs .

Re: Over-enthusiastic OOM killer.

[Dave Jones]

On Wed, 12 Dec 2001, Linus Torvalds wrote:

> >The oom killer just killed a bunch of processes on my workstation.
> >What I don't understand, is why this was deemed necessary, when
> >there was 400MB of buffer cache sitting around in memory, and 175MB
> >of free swap space unused. (66mb of swap was used)
>
> Ehh.. I bet you didn't have free swap.

Difficult to say after the killing, but even if that were the case,
why wasn't buffer cache pruned before the more drastic action ?

After the killing, there was 400MB of real memory, doing absolutely
nothing but holding cached data.

regards,
Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Over-enthusiastic OOM killer.

[Andrew Morton]

Dave Jones wrote:
> 
> On Wed, 12 Dec 2001, Linus Torvalds wrote:
> 
> > >The oom killer just killed a bunch of processes on my workstation.
> > >What I don't understand, is why this was deemed necessary, when
> > >there was 400MB of buffer cache sitting around in memory, and 175MB
> > >of free swap space unused. (66mb of swap was used)
> >
> > Ehh.. I bet you didn't have free swap.
> 
> Difficult to say after the killing, but even if that were the case,
> why wasn't buffer cache pruned before the more drastic action ?
> 
> After the killing, there was 400MB of real memory, doing absolutely
> nothing but holding cached data.
> 

It's a well-known (?) bug in 2.4.17-pre VM.  Anon allocations are
going onto the inactive list, so the inactive list is hugely larger
than the active list.  So this expression in shrink_caches:

	ratio = (unsigned long) nr_pages * nr_active_pages / ((nr_inactive_pages + 1) * 2);	

Evaluates to sero all the time, so we never move any of the buffercache
pages onto the inactive list from where they can be freed.

It can be fixed with

	if (ratio == 0)
		ratio = nr_pages;

It can be fixed by putting anon pages onto the active list in
do_anonymous_page.

It can probably be fixed with Rik's remove-use-once patch.  I
haven't tested that.

It is fixed in the latest -aa patch.

The remaining minor detail is that it isn't fixed in Linux :(

-