linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Minchan Kim <minchan.kim@gmail.com>,
	Thomas Sattler <tsattler@gmx.de>,
	Ury Stankevich <urykhy@gmail.com>,
	Andi Kleen <andi@firstfloor.org>, linux-mm <linux-mm@kvack.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: [PATCH 1/4] mm: compaction: Ensure that the compaction free scanner does not move to the next zone
Date: Tue,  7 Jun 2011 16:07:02 +0100	[thread overview]
Message-ID: <1307459225-4481-2-git-send-email-mgorman@suse.de> (raw)
In-Reply-To: <1307459225-4481-1-git-send-email-mgorman@suse.de>

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
difficult to reproduce on X86-64 is probably just a co-incidence as
the bug should theoritically be possible there.

Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
---
 mm/compaction.c |   13 ++++++++++++-
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 021a296..5c744ab 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -144,9 +144,20 @@ static void isolate_freepages(struct zone *zone,
 	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
-- 
1.7.3.4

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-06-07 15:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-07 15:07 [PATCH 0/4] Fix compaction stalls due to accounting errors in isolated page accounting Mel Gorman
2011-06-07 15:07 ` Mel Gorman [this message]
2011-06-08  9:33   ` [PATCH 1/4] mm: compaction: Ensure that the compaction free scanner does not move to the next zone Michal Hocko
2011-06-07 15:07 ` [PATCH 2/4] mm: vmscan: Do not use page_count without a page pin Mel Gorman
2011-06-07 15:12   ` Minchan Kim
2011-06-08  9:38   ` Michal Hocko
2011-06-07 15:07 ` [PATCH 3/4] mm: memory-failure: Fix isolated page count during memory failure Mel Gorman
2011-06-07 15:14   ` Minchan Kim
2011-06-08 10:07   ` Michal Hocko
2011-06-08 10:11     ` Michal Hocko
2011-06-07 15:07 ` [PATCH 4/4] mm: compaction: Abort compaction if too many pages are isolated and caller is asynchronous Mel Gorman
2011-06-07 15:50   ` Minchan Kim
2011-06-07 16:26     ` Mel Gorman
2011-06-07 16:27     ` [PATCH 4/4] mm: compaction: Abort compaction if too many pages are isolated and caller is asynchronous V2 Mel Gorman
2011-06-07 16:36       ` Minchan Kim
2011-06-08  9:55       ` Michal Hocko
2011-07-17  8:52 ` [PATCH 0/4] Fix compaction stalls due to accounting errors in isolated page accounting Thomas Sattler
2011-07-19  9:16   ` Mel Gorman
2011-07-19 11:24     ` Thomas Sattler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1307459225-4481-2-git-send-email-mgorman@suse.de \
    --to=mgorman@suse.de \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan.kim@gmail.com \
    --cc=tsattler@gmx.de \
    --cc=urykhy@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).