linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Joonsoo Kim <js1304@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Vlastimil Babka <vbabka@suse.cz>, Mel Gorman <mgorman@suse.de>,
	Rik van Riel <riel@redhat.com>,
	David Rientjes <rientjes@google.com>,
	Minchan Kim <minchan@kernel.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: [PATCH v3 4/7] mm/compaction: update defer counter when allocation is expected to succeed
Date: Thu,  3 Dec 2015 16:11:18 +0900	[thread overview]
Message-ID: <1449126681-19647-5-git-send-email-iamjoonsoo.kim@lge.com> (raw)
In-Reply-To: <1449126681-19647-1-git-send-email-iamjoonsoo.kim@lge.com>

It's rather strange that compact_considered and compact_defer_shift aren't
updated but compact_order_failed is updated when allocation is expected
to succeed. Regardless actual allocation success, deferring for current
order will be disabled so it doesn't result in much difference to
compaction behaviour.

Moreover, in the past, there is a gap between expectation for allocation
succeess in compaction and actual success in page allocator. But, now,
this gap would be diminished due to providing classzone_idx and alloc_flags
to watermark check in compaction and changed watermark check criteria
for high-order allocation. Therfore, it's not a big problem to update
defer counter when allocation is expected to succeed. This change
will help to simplify defer logic.

Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
---
 include/linux/compaction.h |  2 --
 mm/compaction.c            | 27 ++++++++-------------------
 mm/page_alloc.c            |  1 -
 3 files changed, 8 insertions(+), 22 deletions(-)

diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index 359b07a..4761611 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -47,8 +47,6 @@ extern unsigned long compaction_suitable(struct zone *zone, int order,
 					int alloc_flags, int classzone_idx);
 
 extern bool compaction_deferred(struct zone *zone, int order);
-extern void compaction_defer_reset(struct zone *zone, int order,
-				bool alloc_success);
 extern bool compaction_restarting(struct zone *zone, int order);
 
 #else
diff --git a/mm/compaction.c b/mm/compaction.c
index f144494..67b8d90 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -158,18 +158,12 @@ bool compaction_deferred(struct zone *zone, int order)
 	return true;
 }
 
-/*
- * Update defer tracking counters after successful compaction of given order,
- * which means an allocation either succeeded (alloc_success == true) or is
- * expected to succeed.
- */
-void compaction_defer_reset(struct zone *zone, int order,
-		bool alloc_success)
+/* Update defer tracking counters after successful compaction of given order */
+static void compaction_defer_reset(struct zone *zone, int order)
 {
-	if (alloc_success) {
-		zone->compact_considered = 0;
-		zone->compact_defer_shift = 0;
-	}
+	zone->compact_considered = 0;
+	zone->compact_defer_shift = 0;
+
 	if (order >= zone->compact_order_failed)
 		zone->compact_order_failed = order + 1;
 
@@ -1568,13 +1562,8 @@ unsigned long try_to_compact_pages(gfp_t gfp_mask, unsigned int order,
 		/* If a normal allocation would succeed, stop compacting */
 		if (zone_watermark_ok(zone, order, low_wmark_pages(zone),
 					ac->classzone_idx, alloc_flags)) {
-			/*
-			 * We think the allocation will succeed in this zone,
-			 * but it is not certain, hence the false. The caller
-			 * will repeat this with true if allocation indeed
-			 * succeeds in this zone.
-			 */
-			compaction_defer_reset(zone, order, false);
+			compaction_defer_reset(zone, order);
+
 			/*
 			 * It is possible that async compaction aborted due to
 			 * need_resched() and the watermarks were ok thanks to
@@ -1669,7 +1658,7 @@ static void __compact_pgdat(pg_data_t *pgdat, struct compact_control *cc)
 
 		if (zone_watermark_ok(zone, cc->order,
 				low_wmark_pages(zone), 0, 0))
-			compaction_defer_reset(zone, cc->order, false);
+			compaction_defer_reset(zone, cc->order);
 	}
 }
 
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7002c66..f3605fd 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2815,7 +2815,6 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
 		struct zone *zone = page_zone(page);
 
 		zone->compact_blockskip_flush = false;
-		compaction_defer_reset(zone, order, true);
 		count_vm_event(COMPACTSUCCESS);
 		return page;
 	}
-- 
1.9.1

--
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>

  parent reply	other threads:[~2015-12-03  7:11 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-03  7:11 [PATCH v3 0/7] mm/compaction: redesign compaction: part1 Joonsoo Kim
2015-12-03  7:11 ` [PATCH v3 1/7] mm/compaction: skip useless pfn when updating cached pfn Joonsoo Kim
2015-12-03 10:36   ` Vlastimil Babka
2015-12-07  7:37     ` Joonsoo Kim
2015-12-03  7:11 ` [PATCH v3 2/7] mm/compaction: remove unused defer_compaction() in compaction.h Joonsoo Kim
2015-12-04 15:29   ` Vlastimil Babka
2015-12-03  7:11 ` [PATCH v3 3/7] mm/compaction: initialize compact_order_failed to MAX_ORDER Joonsoo Kim
2015-12-04 15:36   ` Vlastimil Babka
2015-12-03  7:11 ` Joonsoo Kim [this message]
2015-12-04 16:52   ` [PATCH v3 4/7] mm/compaction: update defer counter when allocation is expected to succeed Vlastimil Babka
2015-12-07  8:03     ` Joonsoo Kim
2015-12-03  7:11 ` [PATCH v3 5/7] mm/compaction: respect compaction order when updating defer counter Joonsoo Kim
2015-12-04 17:15   ` Vlastimil Babka
2015-12-07  8:04     ` Joonsoo Kim
2015-12-03  7:11 ` [PATCH v3 6/7] mm/compaction: introduce migration scan limit Joonsoo Kim
2015-12-14  9:34   ` Vlastimil Babka
2015-12-16  5:39     ` Joonsoo Kim
2015-12-03  7:11 ` [PATCH v3 7/7] mm/compaction: replace compaction deferring with compaction limit Joonsoo Kim
2015-12-14  9:55   ` Vlastimil Babka

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=1449126681-19647-5-git-send-email-iamjoonsoo.kim@lge.com \
    --to=js1304@gmail.com \
    --cc=akpm@linux-foundation.org \
    --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 \
    --cc=vbabka@suse.cz \
    /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).