[Intel-gfx] [PATCH 0/2] Disable Android low memory killer

[Chris Wilson]

On Fri, Sep 26, 2014 at 10:08:54AM +0000, Gore, Tim wrote:
> 
> 
> > -----Original Message-----
> > From: Chris Wilson [mailto:chris at chris-wilson.co.uk]
> > Sent: Friday, September 26, 2014 10:50 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:27:22AM +0100, tim.gore at intel.com wrote:
> > > From: Tim Gore <tim.gore at intel.com>
> > >
> > > For some tests that put pressure on memory, the Android
> > > lowmemorykiller needs to be disabled for the test to run to
> > > completion. The first patch is a simple bit of preparation to ensure
> > > that all (well written) "simple" tests exit via a call to igt_exit, in
> > > the same way as tests with subtests do.
> > > This is to make sure we can clean up by re-enabling the
> > > lowmemorykiller.
> > > The second patch is to disable the Android lowmemorykiller during the
> > > common initialisation code (in oom_adjust_for_doom to be exact) and to
> > > re-enstate it in igt_exit.
> > 
> > Isn't this just a huge red flag that the kernel is incompatible with our UMA
> > allocation strategy and that by masking the issue we will never be motivated
> > to fix it?
> > -Chris
> > 
> 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.

There's the issue that the lowmemorykiller doesn't take into account
that, often quite large amounts, of i915 memory is purgeable (should be
regarded as free by the shrinker). That can and does affect ordinary userspace
clients (for example if a popular desktop distribution enables lowmemkiller...).

The simplest solution would perhaps to be to create a new category of
"late" shrinker for lowmemkiller so that it runs after all the in-kernel
caches are cleaned but before actual swapping.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre