[Intel-gfx] [PATCH 0/2] Disable Android low memory killer
Gore, Tim
tim.gore at intel.com
Fri Sep 26 12:46:48 CEST 2014
> -----Original Message-----
> From: Chris Wilson [mailto:chris at chris-wilson.co.uk]
> Sent: Friday, September 26, 2014 11:30 AM
> To: Gore, Tim
> Cc: intel-gfx at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 0/2] Disable Android low memory killer
>
> On Fri, Sep 26, 2014 at 10:08:54AM +0000, Gore, Tim wrote:
> > I don't think so. This is really just about the Android low memory
> > killer having Different goals to kswapd. Kswapd tries to keep a
> > certain amount of free memory so that the kernel can run smoothly. On
> > Android the lowmemorykiller attempts to maintain somewhat higher
> > levels of free memory by killing off processes, because the user is
> > not expected to ever close anything and expects new applications to
> > open quickly. So if you put the memory under pressure the Android low
> > memory killer will inevitably look for something to kill, and if your
> > test is the only thing running its toast. The linux oom killer is still there, but
> is never needed on Android because the lowmemorykiller gets there first.
>
> Though I think the interaction between lowmemkiller and i915 is broken, I do
> agree that we need to run our swap tests and that to do so we need to
> disable lowmemkiller.
>
> I would prefer it if only the swap-thrash tests disabled the lowmemkiller
> though, as I think we still need to test integration behaviour and if
> lowmemkiller starts killing tests that we think should be well within the limits,
> that is likely to be our bug.
> -Chris
>
We could do it on a test by test basis if people prefer. It just puts the responsibility
on test writers to know when they might trigger the lowmemorykiller. The trouble
is that the kernel is pretty lazy when comes to freeing up memory. You may think
there should be plenty "free", but that doesn't mean those pages are on the free list.
Once kswapd has achieved its high water mark its done. But the lowmemorykiller
always looks for more than the high water mark (its threshold is based on the
high water mark, so is always higher). If you have enough file backed pages you're ok,
but igt tests don't tend to do much file reading.
As for modifying the low memory killer to be more linux friendly, that's a whole
new level of debate!!
Tim
More information about the Intel-gfx
mailing list