Re: [PATCH] staging, android: remove lowmemory killer from the tree

From: Todd Kjos <tkjos@google.com>
To: John Stultz <john.stultz@linaro.org>
Cc: "Michal Hocko" <mhocko@kernel.org>,
	"Greg KH" <gregkh@linuxfoundation.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Riley Andrews" <riandrews@android.com>,
	devel@driverdev.osuosl.org, LKML <linux-kernel@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>, "Michal Hocko" <mhocko@suse.com>,
	"Android Kernel Team" <kernel-team@android.com>,
	"Martijn Coenen" <maco@google.com>,
	"Rom Lemarchand" <romlem@google.com>,
	"Tim Murray" <timmurray@google.com>
Subject: Re: [PATCH] staging, android: remove lowmemory killer from the tree
Date: Thu, 23 Feb 2017 12:28:53 -0800	[thread overview]
Message-ID: <CAHRSSEzvcmc3JMc=CnzBeUVWy2t=DD2WgnysmaHP1fp9B80Aug@mail.gmail.com> (raw)
In-Reply-To: <CANcMJZBNe10dtK8ANtLSWS3UXeePhndN=S5otADhQdfQKOAhOw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]

+timmurray

On Thu, Feb 23, 2017 at 12:24 PM, John Stultz <john.stultz@linaro.org>
wrote:

> On Wed, Feb 22, 2017 at 4:01 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > From: Michal Hocko <mhocko@suse.com>
> >
> > Lowmemory killer is sitting in the staging tree since 2008 without any
> > serious interest for fixing issues brought up by the MM folks. The main
> > objection is that the implementation is basically broken by design:
> >         - it hooks into slab shrinker API which is not suitable for this
> >           purpose. lowmem_count implementation just shows this nicely.
> >           There is no scaling based on the memory pressure and no
> >           feedback to the generic shrinker infrastructure.
> >           Moreover lowmem_scan is called way too often for the heavy
> >           work it performs.
> >         - it is not reclaim context aware - no NUMA and/or memcg
> >           awareness.
> >
> > As the code stands right now it just adds a maintenance overhead when
> > core MM changes have to update lowmemorykiller.c as well. It also seems
> > that the alternative LMK implementation will be solely in the userspace
> > so this code has no perspective it seems. The staging tree is supposed
> > to be for a code which needs to be put in shape before it can be merged
> > which is not the case here obviously.
>
> So, just for context, Android does have a userland LMK daemon (using
> the mempressure notifiers) as you mentioned, but unfortunately I'm
> unaware of any devices that ship with that implementation.
>
> This is reportedly because while the mempressure notifiers provide a
> the signal to userspace, the work the deamon then has to do to look up
> per process memory usage, in order to figure out who is best to kill
> at that point was too costly and resulted in poor device performance.
>
> So for shipping Android devices, the LMK is still needed. However, its
> not critical for basic android development, as the system will
> function without it. Additionally I believe most vendors heavily
> customize the LMK in their vendor tree, so the value of having it in
> staging might be relatively low.
>
> It would be great however to get a discussion going here on what the
> ulmkd needs from the kernel in order to efficiently determine who best
> to kill, and how we might best implement that.
>
> thanks
> -john
>

[-- Attachment #2: Type: text/html, Size: 3046 bytes --]