915e70f926
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. Signed-off-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
||
---|---|---|
.. | ||
acpi | ||
asm-generic | ||
clocksource | ||
crypto | ||
drm | ||
dt-bindings | ||
keys | ||
kvm | ||
linux | ||
math-emu | ||
media | ||
memory | ||
misc | ||
net | ||
pcmcia | ||
ras | ||
rdma | ||
rxrpc | ||
scsi | ||
soc | ||
sound | ||
target | ||
trace | ||
uapi | ||
video | ||
xen | ||
Kbuild |