Re: [PATCH] Remove OOM killer from try_to_free_pages / all_unreclaimablebraindamage

From: Nick Piggin
Date: Tue Nov 09 2004 - 20:12:14 EST




Marcelo Tosatti wrote:

On Mon, Nov 08, 2004 at 06:35:52PM -0800, Andrew Morton wrote:

Nick Piggin <piggin@xxxxxxxxxxxxxxx> wrote:

I'm not sure... it could also be just be a fluke
due to chaotic effects in the mm, I suppose :|

2.6 scans less than 2.4 before declaring oom. I looked at the 2.4
implementation and thought "whoa, that's crazy - let's reduce it and see
who complains". My three-year-old memory tells me it was reduced by 2x to
3x.

We need to find testcases (dammit) and do the analysis. It could be that
we're simply not scanning far enough.


Andrew,

When reading the code I was really suspicious of the all_unreclaimable code. It basically stops scanning when reaching OOM conditions - that might be it.



Yeah, I saw a pretty good correlation between OOM killing and all_unreclaimable.

We've got some code to spit that out during an OOM kill now, so that might be
helpful.

I tried to disable it (ignore it if priority==0) - result: very slow progress on extreme load.



I had a patch that caused try_to_free_pages to ignore all_unreclaimable and
go 'round the loop again if we reached oom-kill conditions. Basically that
guarantees you'll scan ~ pages_present*2 before going OOM. I think it may
be a good thing to do, but I wasn't really able to reproduce these early
OOM killings.

-
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/