Re: OOM kernel behaviour

From: Christoph Lameter
Date: Tue Dec 01 2009 - 11:08:45 EST


On Tue, 1 Dec 2009, Jonathan Miles wrote:

> On 30/11/09 18:57 Christoph Lameter said the following:
> > On Mon, 30 Nov 2009, Jonathan Miles wrote:
> >
> >> I'm running kernel 2.6.31.
> >
> > Are you using a 32 bit kernel?

32 bit kernels are forced to use memory below 1G for some allocations. You
may be running out of memory because the kernel is not able to use all of
memory.

> Yep, that's what I intended. I want to tune my workstation so that it
> doesn't need to use swap. With my workload you can assume that nearly
> all processes are loaded for a reason and that at some point I want to
> use any one of them *now*.

Anonymous page use may fluctuate unpredictably based on the processes
being started. A spike may take out your system.

> > In order to find the reason for the OOM (which has not much to do with
> > memory, the kernel has been unable to reclaim memmory for some reason)
> > you need to look at the debug output that the kernel generates.
>
> I've attached a good example which shows Xorg invoking the OOM killer
> when the page-cache is using ~1.3GB out of 2GB. My understanding from
> reading linux-mm.org is that the kernel actually prefers to swap than
> reclaim from the page-cache... is this accurate? However, what if there
> is no swap, or it's configured not to use it? Should the kernel then try
> to reclaim instead?

The kernel will prefer to reclaim from clean page cache over
swapping in general. The aggressiveness of swap can be controlled via
/proc/sys/vm/swappiness.

The OOM killer output shows that the DMA is zone is marked as
unreclaimable but the allocation causing it is not using DMA. Other zones
all seem to have enough memory. Is this straight 2.6.31? No use of
containers, memory policies etc right?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/