From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f200.google.com (mail-ot0-f200.google.com [74.125.82.200]) by kanga.kvack.org (Postfix) with ESMTP id 40A726B0387 for ; Thu, 23 Feb 2017 15:28:55 -0500 (EST) Received: by mail-ot0-f200.google.com with SMTP id x64so3828502ota.1 for ; Thu, 23 Feb 2017 12:28:55 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com. [2607:f8b0:4003:c0f::22d]) by mx.google.com with ESMTPS id r188si2168136oib.142.2017.02.23.12.28.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Feb 2017 12:28:54 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id j38so1646883otb.3 for ; Thu, 23 Feb 2017 12:28:54 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20170222120121.12601-1-mhocko@kernel.org> From: Todd Kjos Date: Thu, 23 Feb 2017 12:28:53 -0800 Message-ID: Subject: Re: [PATCH] staging, android: remove lowmemory killer from the tree Content-Type: multipart/alternative; boundary=94eb2c19083a3ec86305493876a3 Sender: owner-linux-mm@kvack.org List-ID: To: John Stultz Cc: Michal Hocko , Greg KH , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Riley Andrews , devel@driverdev.osuosl.org, LKML , Linux-MM , Michal Hocko , Android Kernel Team , Martijn Coenen , Rom Lemarchand , Tim Murray --94eb2c19083a3ec86305493876a3 Content-Type: text/plain; charset=UTF-8 +timmurray On Thu, Feb 23, 2017 at 12:24 PM, John Stultz wrote: > On Wed, Feb 22, 2017 at 4:01 AM, Michal Hocko wrote: > > From: Michal Hocko > > > > 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 > --94eb2c19083a3ec86305493876a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+timmurray

On Thu, Feb 23, 2017 at 12:24 PM, John Stultz <john.= stultz@linaro.org> wrote:
O= n 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 mai= n
> objection is that the implementation is basically broken by design: >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- it hooks into slab shrinker API whi= ch is not suitable for this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0purpose. lowmem_count implemen= tation just shows this nicely.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0There is no scaling based on t= he memory pressure and no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0feedback to the generic shrink= er infrastructure.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Moreover lowmem_scan is called= way too often for the heavy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0work it performs.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- it is not reclaim context aware - n= o NUMA and/or memcg
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0awareness.
>
> As the code stands right now it just adds a maintenance overhead when<= br> > core MM changes have to update lowmemorykiller.c as well. It also seem= s
> that the alternative LMK implementation will be solely in the userspac= e
> 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 merge= d
> 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

--94eb2c19083a3ec86305493876a3-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org