OSDN Git Service

mm: compaction: ensure that the compaction free scanner does not move to the next...
authorMel Gorman <mgorman@suse.de>
Tue, 19 Jul 2011 09:15:49 +0000 (10:15 +0100)
committerGreg Kroah-Hartman <gregkh@suse.de>
Wed, 3 Aug 2011 19:42:43 +0000 (12:42 -0700)
commit16d266cc0c634cd38d47eb7acc06bedfce83a9f2
treea03e602a90454ae601b6b0e06d741871ec1fb973
parent950b809e6c27e81d63010ed807605dd50047567e
mm: compaction: ensure that the compaction free scanner does not move to the next zone

commit: 7454f4ba40b419eb999a3c61a99da662bf1a2bb8 upstream

Compaction works with two scanners, a migration and a free scanner.  When
the scanners crossover, migration within the zone is complete.  The
location of the scanner is recorded on each cycle to avoid excesive
scanning.

When a zone is small and mostly reserved, it's very easy for the migration
scanner to be close to the end of the zone.  Then the following situation
can occurs

  o migration scanner isolates some pages near the end of the zone
  o free scanner starts at the end of the zone but finds that the
    migration scanner is already there
  o free scanner gets reinitialised for the next cycle as
    cc->migrate_pfn + pageblock_nr_pages
    moving the free scanner into the next zone
  o migration scanner moves into the next zone

When this happens, NR_ISOLATED accounting goes haywire because some of the
accounting happens against the wrong zone.  One zones counter remains
positive while the other goes negative even though the overall global
count is accurate.  This was reported on X86-32 with !SMP because !SMP
allows the negative counters to be visible.  The fact that it is the bug
should theoritically be possible there.

Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
mm/compaction.c