linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: David Rientjes <rientjes@google.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Mel Gorman <mgorman@techsingularity.net>
Cc: Michal Hocko <mhocko@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>
Subject: [RFC 2/3] mm, page_alloc: reclaim for __GFP_NORETRY costly requests only when compaction was skipped
Date: Tue, 11 Dec 2018 15:29:40 +0100	[thread overview]
Message-ID: <20181211142941.20500-3-vbabka@suse.cz> (raw)
In-Reply-To: <20181211142941.20500-1-vbabka@suse.cz>

For costly __GFP_NORETRY allocations (including THP's) we first do an initial
compaction attempt and if that fails, we proceed with reclaim and another
round of compaction, unless compaction was deferred due to earlier multiple
failures. Andrea proposed [1] that we count all compaction failures as the
defered case in try_to_compact_pages(), but I don't think that's a good idea
in general. Instead, change the __GFP_NORETRY specific condition so that it
only proceeds with further reclaim/compaction when the initial compaction
attempt was skipped due to lack of free base pages.

Note that the original condition probably never worked properly for THP's,
because compaction can only become deferred after a sync compaction failure,
and THP's only perform async compaction, except khugepaged, which is
infrequent, or madvised faults (until the previous patch restored __GFP_NORETRY
for those) which are not the default case. Deferring due to async compaction
failures should be however also beneficial and thus introduced in the next
patch.

Also note that due to how try_to_compact_pages() constructs its return value
from compaction attempts across the whole zonelist, returning COMPACT_SKIPPED
means that compaction was skipped for *all* attempted zones/nodes, which means
all zones/nodes are low on memory at the same moment. This is probably rare,
which would mean that the resulting 'goto nopage' would be very common, just
because e.g. a single zone had enough memory and compaction failed there, while
the rest of nodes could succeed after reclaim.  However, since THP faults use
__GFP_THISNODE, compaction is also attempted only for a single node, so in
practice there should be no significant loss of information when constructing
the return value, nor bias towards 'goto nopage' for THP faults.

[1] https://lkml.kernel.org/r/20181206005425.GB21159@redhat.com

Suggested-by: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Michal Hocko <mhocko@kernel.org>
---
 mm/page_alloc.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 2ec9cc407216..3d83a6093ada 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4129,14 +4129,14 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
 		 */
 		if (costly_order && (gfp_mask & __GFP_NORETRY)) {
 			/*
-			 * If compaction is deferred for high-order allocations,
-			 * it is because sync compaction recently failed. If
-			 * this is the case and the caller requested a THP
-			 * allocation, we do not want to heavily disrupt the
-			 * system, so we fail the allocation instead of entering
-			 * direct reclaim.
+			 * If compaction was skipped because of insufficient
+			 * free pages, proceed with reclaim and another
+			 * compaction attempt. If it failed for other reasons or
+			 * was deferred, do not reclaim and retry, as we do not
+			 * want to heavily disrupt the system for a costly
+			 * __GFP_NORETRY allocation such as THP.
 			 */
-			if (compact_result == COMPACT_DEFERRED)
+			if (compact_result != COMPACT_SKIPPED)
 				goto nopage;
 
 			/*
-- 
2.19.2

  parent reply	other threads:[~2018-12-11 14:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-11 14:29 [RFC 0/3] reduce THP fault thrashing Vlastimil Babka
2018-12-11 14:29 ` [RFC 1/3] mm, thp: restore __GFP_NORETRY for madvised thp fault allocations Vlastimil Babka
2019-01-08 11:16   ` Mel Gorman
2019-01-10 13:52     ` Vlastimil Babka
2019-01-10 14:55       ` Mel Gorman
2018-12-11 14:29 ` Vlastimil Babka [this message]
2019-01-08 11:25   ` [RFC 2/3] mm, page_alloc: reclaim for __GFP_NORETRY costly requests only when compaction was skipped Mel Gorman
2018-12-11 14:29 ` [RFC 3/3] mm, compaction: introduce deferred async compaction Vlastimil Babka
2019-01-08 11:28   ` Mel Gorman

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=20181211142941.20500-3-vbabka@suse.cz \
    --to=vbabka@suse.cz \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --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 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).