• Andy Whitcroft's avatar
    synchronous lumpy reclaim: ensure we count pages transitioning inactive via clear_active_flags · e9187bdc
    Andy Whitcroft authored
    As pointed out by Mel when reclaim is applied at higher orders a significant
    amount of IO may be started.  As this takes finite time to drain reclaim will
    consider more areas than ultimatly needed to satisfy the request.  This leads
    to more reclaim than strictly required and reduced success rates.
    
    I was able to confirm Mel's test results on systems locally.  These show that
    even under light load the success rates drop off far more than expected.
    Testing with a modified version of his patch (which follows) I was able to
    allocate almost all of ZONE_MOVABLE with a near idle system.  I ran 5 test
    passes sequentially following system boot (the system has 29 hugepages in
    ZONE_MOVABLE):
    
      2.6.23-rc1              11  8  6  7  7
      sync_lumpy              28 28 29 29 26
    
    These show that although hugely better than the near 0% success normally
    expected we can only allocate about a 1/4 of the zone.  Using synchronous
    reclaim for these allocations we get close to 100% as expected.
    
    I have also run our standard high order tests and these show no regressions in
    allocation success rates at rest, and some significant improvements under
    load.
    
    This patch:
    
    We are transitioning pages from active to inactive in clear_active_flags,
    those need counting as PGDEACTIVATE vm events.
    Signed-off-by: default avatarAndy Whitcroft <apw@shadowen.org>
    Acked-by: default avatarMel Gorman <mel@csn.ul.ie>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    e9187bdc
vmscan.c 50 KB