Re: oom-killer killing even if memory is available?

[Heiko Carstens <heiko.carstens@de.ibm.com>]

On Tue, 17 Mar 2009 20:51:13 +1100
Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> On Tuesday 17 March 2009 20:00:49 Heiko Carstens wrote:
> > the below looks like there is some bug in the memory management code.
> > Even if there seems to be plenty of memory available the oom-killer
> > kills processes.
> >
> > The below happened after 27 days uptime, memory seems to be heavily
> > fragmented,
> 
> What slab allocator are you using?

That was SLAB.

> > but there are stills larger portions of memory free that
> > could satisfy an order 2 allocation. Any idea why this fails?
> 
> We still keep some watermarks around for higher order pages (for
> GFP_ATOMIC and page reclaim etc purposes).
> 
> Possibly it is being a bit aggressive with the higher orders; when I
> added it I just made a guess at a sane function. See
> mm/page_alloc.c:zone_watermark_ok(). In particular, the for loop at the
> end of the function is the slowpath where it is calculating higher
> order watermarks. The min >>= 1 statement, 1 could be replaced with 2.
> Or we could just keep reserves for 0..PAGE_ALLOC_COSTLY_ORDER and then
> give away _any_ free pages for higher orders than that.
> 
> Still would seem to just prolong the inevitable? Exploding after 27 days
> of uptime is rather sad :(

Yes, it seems to look more like a memory leak. Hmm..

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>