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. 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
