From: Vlastimil Babka <vbabka@suse.cz>
To: linux-mm@kvack.org, Aaron Lu <aaron.lu@intel.com>
Cc: linux-kernel@vger.kernel.org,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Rik van Riel <riel@redhat.com>,
David Rientjes <rientjes@google.com>,
Mel Gorman <mgorman@suse.de>, Minchan Kim <minchan@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>
Subject: [RFC 1/3] mm, compaction: reduce spurious pcplist drains
Date: Thu, 3 Dec 2015 09:10:45 +0100 [thread overview]
Message-ID: <1449130247-8040-2-git-send-email-vbabka@suse.cz> (raw)
In-Reply-To: <1449130247-8040-1-git-send-email-vbabka@suse.cz>
Compaction drains the local pcplists each time migration scanner moves away
from a cc->order aligned block where it isolated pages for migration, so that
the pages freed by migrations can merge into highero orders.
The detection is currently coarser than it could be. The cc->last_migrated_pfn
variable should track the lowest pfn that was isolated for migration. But it
is set to the pfn where isolate_migratepages_block() starts scanning, which is
typically the first pfn of the pageblock. There, the scanner might fail to
isolate several order-aligned blocks, and then isolate COMPACT_CLUSTER_MAX in
another block. This would cause the pcplists drain to be performed, although
the scanner didn't yet finish the block where it isolated from.
This patch thus makes cc->last_migrated_pfn handling more accurate by setting
it to the pfn of an actually isolated page in isolate_migratepages_block().
Although practical effects of this patch are likely low, it arguably makes the
intent of the code more obvious. Also the next patch will make async direct
compaction skip blocks more aggressively, and draining pcplists due to skipped
blocks is wasteful.
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
mm/compaction.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index de3e1e71cd9f..9c14d10ad3e5 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -815,6 +815,15 @@ isolate_migratepages_block(struct compact_control *cc, unsigned long low_pfn,
cc->nr_migratepages++;
nr_isolated++;
+ /*
+ * Record where we could have freed pages by migration and not
+ * yet flushed them to buddy allocator.
+ * - this is the lowest page that was isolated and likely be
+ * then freed by migration.
+ */
+ if (!cc->last_migrated_pfn)
+ cc->last_migrated_pfn = low_pfn;
+
/* Avoid isolating too much */
if (cc->nr_migratepages == COMPACT_CLUSTER_MAX) {
++low_pfn;
@@ -1104,7 +1113,6 @@ static isolate_migrate_t isolate_migratepages(struct zone *zone,
struct compact_control *cc)
{
unsigned long low_pfn, end_pfn;
- unsigned long isolate_start_pfn;
struct page *page;
const isolate_mode_t isolate_mode =
(sysctl_compact_unevictable_allowed ? ISOLATE_UNEVICTABLE : 0) |
@@ -1153,7 +1161,6 @@ static isolate_migrate_t isolate_migratepages(struct zone *zone,
continue;
/* Perform the isolation */
- isolate_start_pfn = low_pfn;
low_pfn = isolate_migratepages_block(cc, low_pfn, end_pfn,
isolate_mode);
@@ -1163,15 +1170,6 @@ static isolate_migrate_t isolate_migratepages(struct zone *zone,
}
/*
- * Record where we could have freed pages by migration and not
- * yet flushed them to buddy allocator.
- * - this is the lowest page that could have been isolated and
- * then freed by migration.
- */
- if (cc->nr_migratepages && !cc->last_migrated_pfn)
- cc->last_migrated_pfn = isolate_start_pfn;
-
- /*
* Either we isolated something and proceed with migration. Or
* we failed and compact_zone should decide if we should
* continue or not.
--
2.6.3
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-12-03 8:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-03 8:10 [RFC 0/3] reduce latency of direct async compaction Vlastimil Babka
2015-12-03 8:10 ` Vlastimil Babka [this message]
2015-12-03 8:10 ` [RFC 2/3] mm, compaction: make async direct compaction skip blocks where isolation fails Vlastimil Babka
2015-12-03 8:10 ` [RFC 3/3] mm, compaction: direct freepage allocation for async direct compaction Vlastimil Babka
2015-12-03 9:25 ` [RFC 0/3] reduce latency of direct async compaction Aaron Lu
2015-12-03 9:38 ` Vlastimil Babka
2015-12-03 11:35 ` Aaron Lu
2015-12-03 11:52 ` Aaron Lu
2015-12-04 12:34 ` Vlastimil Babka
2015-12-07 7:35 ` Joonsoo Kim
2015-12-07 8:59 ` Aaron Lu
2015-12-08 0:41 ` Joonsoo Kim
2015-12-08 5:14 ` Aaron Lu
2015-12-08 6:51 ` Joonsoo Kim
2015-12-08 8:52 ` Aaron Lu
2015-12-09 0:33 ` Joonsoo Kim
2015-12-09 5:40 ` Aaron Lu
2015-12-10 4:35 ` Joonsoo Kim
2015-12-10 6:15 ` Aaron Lu
2015-12-04 6:25 ` Aaron Lu
2015-12-04 12:38 ` Vlastimil Babka
2015-12-07 3:14 ` Aaron Lu
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=1449130247-8040-2-git-send-email-vbabka@suse.cz \
--to=vbabka@suse.cz \
--cc=aaron.lu@intel.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=minchan@kernel.org \
--cc=riel@redhat.com \
--cc=rientjes@google.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).