On Thu 23-02-17 12:24:57, John Stultz wrote: > On Wed, Feb 22, 2017 at 4:01 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > From: Michal Hocko <mhocko@xxxxxxxx> > > > > 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. What was the expensive part? > 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. This is even a stronger reason to drop it from the tree. We do not want to maintain the code which is not used in fact. > 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. I would really like to see this happen and, to be honest, it should have happened quite some time ago (around the time when the lmk was merged to the staging tree). -- Michal Hocko SUSE Labs _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
