• Vladimir Davydov's avatar
    mm: vmscan: shrink all slab objects if tight on memory · 0b1fb40a
    Vladimir Davydov authored
    When reclaiming kmem, we currently don't scan slabs that have less than
    batch_size objects (see shrink_slab_node()):
    
            while (total_scan >= batch_size) {
                    shrinkctl->nr_to_scan = batch_size;
                    shrinker->scan_objects(shrinker, shrinkctl);
                    total_scan -= batch_size;
            }
    
    If there are only a few shrinkers available, such a behavior won't cause
    any problems, because the batch_size is usually small, but if we have a
    lot of slab shrinkers, which is perfectly possible since FS shrinkers
    are now per-superblock, we can end up with hundreds of megabytes of
    practically unreclaimable kmem objects.  For instance, mounting a
    thousand of ext2 FS images with a hundred of files in each and iterating
    over all the files using du(1) will result in about 200 Mb of FS caches
    that cannot be dropped even with the aid of the vm.drop_caches sysctl!
    
    This problem was initially pointed out by Glauber Costa [*].  Glauber
    proposed to fix it by making the shrink_slab() always take at least one
    pass, to put it simply, turning the scan loop above to a do{}while()
    loop.  However, this proposal was rejected, because it could result in
    more aggressive and frequent slab shrinking even under low memory
    pressure when total_scan is naturally very small.
    
    This patch is a slightly modified version of Glauber's approach.
    Similarly to Glauber's patch, it makes shrink_slab() scan less than
    batch_size objects, but only if the total number of objects we want to
    scan (total_scan) is greater than the total number of objects available
    (max_pass).  Since total_scan is biased as half max_pass if the current
    delta change is small:
    
            if (delta < max_pass / 4)
                    total_scan = min(total_scan, max_pass / 2);
    
    this is only possible if we are scanning at high prio.  That said, this
    patch shouldn't change the vmscan behaviour if the memory pressure is
    low, but if we are tight on memory, we will do our best by trying to
    reclaim all available objects, which sounds reasonable.
    
    [*] http://www.spinics.net/lists/cgroups/msg06913.htmlSigned-off-by: default avatarVladimir Davydov <vdavydov@parallels.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Dave Chinner <dchinner@redhat.com>
    Cc: Glauber Costa <glommer@gmail.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    0b1fb40a
vmscan.c 108 KB