Skip to content
  • Mel Gorman's avatar
    mm: vmscan: kswapd should not free an excessive number of pages when balancing small zones · 8afdcece
    Mel Gorman authored
    When reclaiming for order-0 pages, kswapd requires that all zones be
    balanced.  Each cycle through balance_pgdat() does background ageing on
    all zones if necessary and applies equal pressure on the inactive zone
    unless a lot of pages are free already.
    
    A "lot of free pages" is defined as a "balance gap" above the high
    watermark which is currently 7*high_watermark.  Historically this was
    reasonable as min_free_kbytes was small.  However, on systems using huge
    pages, it is recommended that min_free_kbytes is higher and it is tuned
    with hugeadm --set-recommended-min_free_kbytes.  With the introduction of
    transparent huge page support, this recommended value is also applied.  On
    X86-64 with 4G of memory, min_free_kbytes becomes 67584 so one would
    expect around 68M of memory to be free.  The Normal zone is approximately
    35000 pages so under even normal memory pressure such as copying a large
    file, it gets exhausted quickly.  As it is getting exhausted, kswapd
    applies pressure equally to all zones, including the DMA32 zone.  DMA32 is
    approximately 700,000 pages with a high watermark of around 23,000 pages.
    In this situation, kswapd will reclaim around (23000*8 where 8 is the high
    watermark + balance gap of 7 * high watermark) pages or 718M of pages
    before the zone is ignored.  What the user sees is that free memory far
    higher than it should be.
    
    To avoid an excessive number of pages being reclaimed from the larger
    zones, explicitely defines the "balance gap" to be either 1% of the zone
    or the low watermark for the zone, whichever is smaller.  While kswapd
    will check all zones to apply pressure, it'll ignore zones that meets the
    (high_wmark + balance_gap) watermark.
    
    To test this, 80G were copied from a partition and the amount of memory
    being used was recorded.  A comparison of a patch and unpatched kernel can
    be seen at
    http://www.csn.ul.ie/~mel/postings/minfree-20110222/memory-usage-hydra.ps
    
    
    and shows that kswapd is not reclaiming as much memory with the patch
    applied.
    
    Signed-off-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
    Signed-off-by: default avatarMel Gorman <mel@csn.ul.ie>
    Acked-by: default avatarRik van Riel <riel@redhat.com>
    Cc: Shaohua Li <shaohua.li@intel.com>
    Cc: "Chen, Tim C" <tim.c.chen@intel.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    8afdcece