This is a note to let you know that I've just added the patch titled
mm: compaction: ensure that the compaction free scanner does not move to
the next zone
to the 2.6.39-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mm-compaction-ensure-that-the-compaction-free-scanner-does-not-move-to-the-next-zone.patch
and it can be found in the queue-2.6.39 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From [email protected] Mon Aug 1 11:41:52 2011
From: Mel Gorman <[email protected]>
Date: Tue, 19 Jul 2011 10:15:49 +0100
Subject: mm: compaction: ensure that the compaction free scanner does not move
to the next zone
To: [email protected]
Cc: Andrea Arcangeli <[email protected]>, Andrew Morton
<[email protected]>, Thomas Sattler <[email protected]>, Mel Gorman
<[email protected]>
Message-ID: <[email protected]>
From: Mel Gorman <[email protected]>
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 <[email protected]>
Reviewed-by: Minchan Kim <[email protected]>
Reviewed-by: Michal Hocko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/compaction.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -144,9 +144,20 @@ static void isolate_freepages(struct zon
int nr_freepages = cc->nr_freepages;
struct list_head *freelist = &cc->freepages;
+ /*
+ * Initialise the free scanner. The starting point is where we last
+ * scanned from (or the end of the zone if starting). The low point
+ * is the end of the pageblock the migration scanner is using.
+ */
pfn = cc->free_pfn;
low_pfn = cc->migrate_pfn + pageblock_nr_pages;
- high_pfn = low_pfn;
+
+ /*
+ * Take care that if the migration scanner is at the end of the zone
+ * that the free scanner does not accidentally move to the next zone
+ * in the next isolation cycle.
+ */
+ high_pfn = min(low_pfn, pfn);
/*
* Isolate free pages until enough are available to migrate the
Patches currently in stable-queue which might be from [email protected] are
queue-2.6.39/mm-vmscan-evaluate-the-watermarks-against-the-correct.patch
queue-2.6.39/mm-compaction-ensure-that-the-compaction-free-scanner-does-not-move-to-the-next-zone.patch
queue-2.6.39/mm-vmscan-do-not-apply-pressure-to-slab-if-we-are-not-applying-pressure-to-zone.patch
queue-2.6.39/mm-vmscan-do-not-use-page_count-without-a-page-pin.patch
queue-2.6.39/vmscan-fix-a-livelock-in-kswapd.patch
queue-2.6.39/mm-vmscan-correct-check-for-kswapd-sleeping-in.patch
queue-2.6.39/mm-compaction-abort-compaction-if-too-many-pages-are-isolated-and-caller-is-asynchronous-v2.patch
queue-2.6.39/mm-vmscan-only-read-new_classzone_idx-from-pgdat-when-reclaiming-successfully.patch
_______________________________________________
stable mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stable
