]> git.baikalelectronics.ru Git - kernel.git/commit
synchronous lumpy reclaim: ensure we count pages transitioning inactive via clear_act...
authorAndy Whitcroft <apw@shadowen.org>
Wed, 22 Aug 2007 21:01:25 +0000 (14:01 -0700)
committerLinus Torvalds <torvalds@woody.linux-foundation.org>
Thu, 23 Aug 2007 02:52:45 +0000 (19:52 -0700)
commit7d5d5a69fd545cde33c1441e5a649be0cb601542
tree5393cb22c5aef33ec27fa23d633ea088a6066c13
parentbe9fe1aee603e520213d9c57d0d4d7519016d12e
synchronous lumpy reclaim: ensure we count pages transitioning inactive via clear_active_flags

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: Andy Whitcroft <apw@shadowen.org>
Acked-by: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm/vmscan.c