Re: [PATCH] Remove OOM killer from try_to_free_pages / all_unreclaimable braindamage

[Nick Piggin <piggin@cyberone.com.au>]

Marcelo Tosatti wrote:

>On Mon, Nov 08, 2004 at 06:35:52PM -0800, Andrew Morton wrote:
>
>>Nick Piggin <piggin@cyberone.com.au> 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.