Re: [RFC 12/13] mm, compaction: more reliably increase direct compaction priority

All of lore.kernel.org
 help / color / mirror / Atom feed

From: Vlastimil Babka <vbabka@suse.cz>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Rik van Riel <riel@redhat.com>,
	David Rientjes <rientjes@google.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC 12/13] mm, compaction: more reliably increase direct compaction priority
Date: Tue, 10 May 2016 14:55:14 +0200	[thread overview]
Message-ID: <5731DA32.7090707@suse.cz> (raw)
In-Reply-To: <1462865763-22084-13-git-send-email-vbabka@suse.cz>

On 05/10/2016 09:36 AM, Vlastimil Babka wrote:
>   	/*
> -	 * compaction considers all the zone as desperately out of memory
> -	 * so it doesn't really make much sense to retry except when the
> -	 * failure could be caused by insufficient priority
> +	 * Compaction backed off due to watermark checks for order-0
> +	 * so the regular reclaim has to try harder and reclaim something
> +	 * Retry only if it looks like reclaim might have a chance.
>   	 */
> -	if (compaction_failed(compact_result)) {
> -		if (*compact_priority > 0) {
> -			(*compact_priority)--;
> -			return true;
> -		}
> -		return false;
> -	}

Oops, looks like my editing resulted in compaction_failed() check to be
removed completely, which wasn't intentional and can lead to infinite
loops. This should be added on top.

----8<----

WARNING: multiple messages have this Message-ID (diff)

From: Vlastimil Babka <vbabka@suse.cz>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Rik van Riel <riel@redhat.com>,
	David Rientjes <rientjes@google.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC 12/13] mm, compaction: more reliably increase direct compaction priority
Date: Tue, 10 May 2016 14:55:14 +0200	[thread overview]
Message-ID: <5731DA32.7090707@suse.cz> (raw)
In-Reply-To: <1462865763-22084-13-git-send-email-vbabka@suse.cz>

On 05/10/2016 09:36 AM, Vlastimil Babka wrote:
>   	/*
> -	 * compaction considers all the zone as desperately out of memory
> -	 * so it doesn't really make much sense to retry except when the
> -	 * failure could be caused by insufficient priority
> +	 * Compaction backed off due to watermark checks for order-0
> +	 * so the regular reclaim has to try harder and reclaim something
> +	 * Retry only if it looks like reclaim might have a chance.
>   	 */
> -	if (compaction_failed(compact_result)) {
> -		if (*compact_priority > 0) {
> -			(*compact_priority)--;
> -			return true;
> -		}
> -		return false;
> -	}

Oops, looks like my editing resulted in compaction_failed() check to be
removed completely, which wasn't intentional and can lead to infinite
loops. This should be added on top.

----8<----
>From 59a2b38689aa451f661c964dc9bfb990736ad92d Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <vbabka@suse.cz>
Date: Tue, 10 May 2016 14:51:03 +0200
Subject: [PATCH 15/15] fixup! mm, compaction: more reliably increase direct
 compaction priority

---
 mm/page_alloc.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index fa49eb4a5919..e8a0d33cfb67 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3268,6 +3268,14 @@ should_compact_retry(struct alloc_context *ac, int order, int alloc_flags,
 	}
 
 	/*
+	 * Compaction considers all the zones as unfixably fragmented and we
+	 * are on the highest priority, which means it can't be due to
+	 * heuristics and it doesn't really make much sense to retry.
+	 */
+	if (compaction_failed(compact_result))
+		return false;
+
+	/*
 	 * The remaining possibility is that compaction made progress and
 	 * created a high-order page, but it was allocated by somebody else.
 	 * To prevent thrashing, limit the number of retries in such case.
-- 
2.8.2

next prev parent reply	other threads:[~2016-05-10 12:55 UTC|newest]

Thread overview: 122+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-10  7:35 [RFC 00/13] make direct compaction more deterministic Vlastimil Babka
2016-05-10  7:35 ` Vlastimil Babka
2016-05-10  7:35 ` [RFC 01/13] mm, compaction: don't isolate PageWriteback pages in MIGRATE_SYNC_LIGHT mode Vlastimil Babka
2016-05-10  7:35   ` Vlastimil Babka
2016-05-11 12:40   ` Michal Hocko
2016-05-11 12:40     ` Michal Hocko
2016-05-10  7:35 ` [RFC 02/13] mm, page_alloc: set alloc_flags only once in slowpath Vlastimil Babka
2016-05-10  7:35   ` Vlastimil Babka
2016-05-10 11:28   ` Tetsuo Handa
2016-05-10 11:28     ` Tetsuo Handa
2016-05-10 12:30     ` Vlastimil Babka
2016-05-10 12:30       ` Vlastimil Babka
2016-05-12 12:41       ` Michal Hocko
2016-05-12 12:41         ` Michal Hocko
2016-05-31  6:20       ` Joonsoo Kim
2016-05-31  6:20         ` Joonsoo Kim
2016-05-31  7:59         ` Vlastimil Babka
2016-05-31  7:59           ` Vlastimil Babka
2016-06-02  1:50           ` Joonsoo Kim
2016-06-02  1:50             ` Joonsoo Kim
2016-05-10  7:35 ` [RFC 03/13] mm, page_alloc: don't retry initial attempt " Vlastimil Babka
2016-05-10  7:35   ` Vlastimil Babka
2016-05-12 12:48   ` Michal Hocko
2016-05-12 12:48     ` Michal Hocko
2016-05-31  6:25   ` Joonsoo Kim
2016-05-31  6:25     ` Joonsoo Kim
2016-05-31 12:03     ` Vlastimil Babka
2016-05-31 12:03       ` Vlastimil Babka
2016-05-10  7:35 ` [RFC 04/13] mm, page_alloc: restructure direct compaction handling " Vlastimil Babka
2016-05-10  7:35   ` Vlastimil Babka
2016-05-12 13:29   ` Michal Hocko
2016-05-12 13:29     ` Michal Hocko
2016-05-13  8:10     ` Vlastimil Babka
2016-05-13  8:10       ` Vlastimil Babka
2016-05-13  8:31       ` Michal Hocko
2016-05-13  8:31         ` Michal Hocko
2016-05-10  7:35 ` [RFC 05/13] mm, page_alloc: make THP-specific decisions more generic Vlastimil Babka
2016-05-10  7:35   ` Vlastimil Babka
2016-05-12 13:43   ` Michal Hocko
2016-05-12 13:43     ` Michal Hocko
2016-05-10  7:35 ` [RFC 06/13] mm, thp: remove __GFP_NORETRY from khugepaged and madvised allocations Vlastimil Babka
2016-05-10  7:35   ` Vlastimil Babka
2016-05-12 16:20   ` Michal Hocko
2016-05-12 16:20     ` Michal Hocko
2016-05-13  8:23     ` Vlastimil Babka
2016-05-13  8:23       ` Vlastimil Babka
2016-05-13 12:05       ` Michal Hocko
2016-05-13 12:05         ` Michal Hocko
2016-05-18 11:59         ` Vlastimil Babka
2016-05-18 11:59           ` Vlastimil Babka
2016-05-18 15:24           ` Michal Hocko
2016-05-18 15:24             ` Michal Hocko
2016-05-20 13:57             ` Vlastimil Babka
2016-05-20 13:57               ` Vlastimil Babka
2016-05-23  8:39               ` Michal Hocko
2016-05-23  8:39                 ` Michal Hocko
2016-05-10  7:35 ` [RFC 07/13] mm, compaction: introduce direct compaction priority Vlastimil Babka
2016-05-10  7:35   ` Vlastimil Babka
2016-05-13 12:37   ` Michal Hocko
2016-05-13 12:37     ` Michal Hocko
2016-05-10  7:35 ` [RFC 08/13] mm, compaction: simplify contended compaction handling Vlastimil Babka
2016-05-10  7:35   ` Vlastimil Babka
2016-05-13 13:09   ` Michal Hocko
2016-05-13 13:09     ` Michal Hocko
2016-05-16  7:10     ` Vlastimil Babka
2016-05-16  7:10       ` Vlastimil Babka
2016-05-10  7:35 ` [RFC 09/13] mm, compaction: make whole_zone flag ignore cached scanner positions Vlastimil Babka
2016-05-10  7:35   ` Vlastimil Babka
2016-05-13 13:23   ` Michal Hocko
2016-05-13 13:23     ` Michal Hocko
2016-05-10  7:36 ` [RFC 10/13] mm, compaction: cleanup unused functions Vlastimil Babka
2016-05-10  7:36   ` Vlastimil Babka
2016-05-10  7:36 ` [RFC 11/13] mm, compaction: add the ultimate direct compaction priority Vlastimil Babka
2016-05-10  7:36   ` Vlastimil Babka
2016-05-13 13:38   ` Michal Hocko
2016-05-13 13:38     ` Michal Hocko
2016-05-16  7:17     ` Vlastimil Babka
2016-05-16  7:17       ` Vlastimil Babka
2016-05-16  8:11       ` Michal Hocko
2016-05-16  8:11         ` Michal Hocko
2016-05-18 12:46       ` Vlastimil Babka
2016-05-18 12:46         ` Vlastimil Babka
2016-05-10  7:36 ` [RFC 12/13] mm, compaction: more reliably increase " Vlastimil Babka
2016-05-10  7:36   ` Vlastimil Babka
2016-05-10 12:55   ` Vlastimil Babka [this message]
2016-05-10 12:55     ` Vlastimil Babka
2016-05-13 14:15   ` Michal Hocko
2016-05-13 14:15     ` Michal Hocko
2016-05-16  7:31     ` Vlastimil Babka
2016-05-16  7:31       ` Vlastimil Babka
2016-05-16  8:14       ` Michal Hocko
2016-05-16  8:14         ` Michal Hocko
2016-05-16  9:27         ` Vlastimil Babka
2016-05-16  9:27           ` Vlastimil Babka
2016-05-16  9:52           ` Michal Hocko
2016-05-16  9:52             ` Michal Hocko
2016-05-31  6:37   ` Joonsoo Kim
2016-05-31  6:37     ` Joonsoo Kim
2016-05-31 12:07     ` Vlastimil Babka
2016-05-31 12:07       ` Vlastimil Babka
2016-05-31 12:29       ` Vlastimil Babka
2016-05-31 12:29         ` Vlastimil Babka
2016-06-02  2:50         ` Joonsoo Kim
2016-06-02  2:50           ` Joonsoo Kim
2016-05-10  7:36 ` [RFC 13/13] mm, compaction: fix and improve watermark handling Vlastimil Babka
2016-05-10  7:36   ` Vlastimil Babka
2016-05-16  9:25   ` Michal Hocko
2016-05-16  9:25     ` Michal Hocko
2016-05-16  9:50     ` Vlastimil Babka
2016-05-16  9:50       ` Vlastimil Babka
2016-05-16 12:30       ` Michal Hocko
2016-05-16 12:30         ` Michal Hocko
2016-05-18 13:50     ` Mel Gorman
2016-05-18 13:50       ` Mel Gorman
2016-05-18 14:27       ` Michal Hocko
2016-05-18 14:27         ` Michal Hocko
2016-05-18 14:40         ` Mel Gorman
2016-05-18 14:40           ` Mel Gorman
2016-05-17 20:01 ` [RFC 00/13] make direct compaction more deterministic Michal Hocko
2016-05-17 20:01   ` Michal Hocko
2016-05-18  7:19   ` Vlastimil Babka
2016-05-18  7:19     ` Vlastimil Babka

find likely ancestor, descendant, or conflicting patches for this message:
( dfblob:fa49eb4a591 dfblob:e8a0d33cfb6 )
 OR (
bs:"fixup! mm, compaction: more reliably increase direct" )
	(help)

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=5731DA32.7090707@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=riel@redhat.com \
    --cc=rientjes@google.com \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.