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 11/13] mm, compaction: add the ultimate direct compaction priority
Date: Mon, 16 May 2016 09:17:11 +0200 [thread overview]
Message-ID: <573973F7.7070202@suse.cz> (raw)
In-Reply-To: <20160513133851.GP20141@dhcp22.suse.cz>
On 05/13/2016 03:38 PM, Michal Hocko wrote:
> On Tue 10-05-16 09:36:01, Vlastimil Babka wrote:
>> During reclaim/compaction loop, it's desirable to get a final answer from
>> unsuccessful compaction so we can either fail the allocation or invoke the OOM
>> killer. However, heuristics such as deferred compaction or pageblock skip bits
>> can cause compaction to skip parts or whole zones and lead to premature OOM's,
>> failures or excessive reclaim/compaction retries.
>>
>> To remedy this, we introduce a new direct compaction priority called
>> COMPACT_PRIO_SYNC_FULL, which instructs direct compaction to:
>>
>> - ignore deferred compaction status for a zone
>> - ignore pageblock skip hints
>> - ignore cached scanner positions and scan the whole zone
>> - use MIGRATE_SYNC migration mode
>
> I do not think we can do MIGRATE_SYNC because fallback_migrate_page
> would trigger pageout and we are in the allocation path and so we
> could blow up the stack.
Ah, I thought it was just waiting for the writeout to complete, and you
wanted to introduce another migrate mode to actually do the writeout.
But looks like I misremembered.
>> The new priority should get eventually picked up by should_compact_retry() and
>> this should improve success rates for costly allocations using __GFP_RETRY,
>
> s@__GFP_RETRY@__GFP_REPEAT@
Ah thanks. Depending on the patch timing it might be __GFP_RETRY_HARD in
the end, right :)
>> such as hugetlbfs allocations, and reduce some corner-case OOM's for non-costly
>> allocations.
>
> My testing has shown that even with the current implementation with
> deferring, skip hints and cached positions had (close to) 100% success
> rate even with close to OOM conditions.
Hmm, I thought you at one point said that ignoring skip hints was a
large improvement, because the current resetting of them is just too fuzzy.
> I am wondering whether this strongest priority should be done only for
> !costly high order pages. But we probably want less special cases
> between costly and !costly orders.
Yeah, if somebody wants to retry hard, let him.
>> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>
> Acked-by: Michal Hocko <mhocko@suse.com>
>
>> ---
>> include/linux/compaction.h | 1 +
>> mm/compaction.c | 15 ++++++++++++---
>> 2 files changed, 13 insertions(+), 3 deletions(-)
>>
> [...]
>> @@ -1631,7 +1639,8 @@ enum compact_result try_to_compact_pages(gfp_t gfp_mask, unsigned int order,
>> ac->nodemask) {
>> enum compact_result status;
>>
>> - if (compaction_deferred(zone, order)) {
>> + if (prio > COMPACT_PRIO_SYNC_FULL
>> + && compaction_deferred(zone, order)) {
>> rc = max_t(enum compact_result, COMPACT_DEFERRED, rc);
>> continue;
>> }
>
> Wouldn't it be better to pull the prio check into compaction_deferred
> directly? There are more callers and I am not really sure all of them
> would behave consistently.
I'll check, thanks.
--
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>
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 11/13] mm, compaction: add the ultimate direct compaction priority
Date: Mon, 16 May 2016 09:17:11 +0200 [thread overview]
Message-ID: <573973F7.7070202@suse.cz> (raw)
In-Reply-To: <20160513133851.GP20141@dhcp22.suse.cz>
On 05/13/2016 03:38 PM, Michal Hocko wrote:
> On Tue 10-05-16 09:36:01, Vlastimil Babka wrote:
>> During reclaim/compaction loop, it's desirable to get a final answer from
>> unsuccessful compaction so we can either fail the allocation or invoke the OOM
>> killer. However, heuristics such as deferred compaction or pageblock skip bits
>> can cause compaction to skip parts or whole zones and lead to premature OOM's,
>> failures or excessive reclaim/compaction retries.
>>
>> To remedy this, we introduce a new direct compaction priority called
>> COMPACT_PRIO_SYNC_FULL, which instructs direct compaction to:
>>
>> - ignore deferred compaction status for a zone
>> - ignore pageblock skip hints
>> - ignore cached scanner positions and scan the whole zone
>> - use MIGRATE_SYNC migration mode
>
> I do not think we can do MIGRATE_SYNC because fallback_migrate_page
> would trigger pageout and we are in the allocation path and so we
> could blow up the stack.
Ah, I thought it was just waiting for the writeout to complete, and you
wanted to introduce another migrate mode to actually do the writeout.
But looks like I misremembered.
>> The new priority should get eventually picked up by should_compact_retry() and
>> this should improve success rates for costly allocations using __GFP_RETRY,
>
> s@__GFP_RETRY@__GFP_REPEAT@
Ah thanks. Depending on the patch timing it might be __GFP_RETRY_HARD in
the end, right :)
>> such as hugetlbfs allocations, and reduce some corner-case OOM's for non-costly
>> allocations.
>
> My testing has shown that even with the current implementation with
> deferring, skip hints and cached positions had (close to) 100% success
> rate even with close to OOM conditions.
Hmm, I thought you at one point said that ignoring skip hints was a
large improvement, because the current resetting of them is just too fuzzy.
> I am wondering whether this strongest priority should be done only for
> !costly high order pages. But we probably want less special cases
> between costly and !costly orders.
Yeah, if somebody wants to retry hard, let him.
>> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>
> Acked-by: Michal Hocko <mhocko@suse.com>
>
>> ---
>> include/linux/compaction.h | 1 +
>> mm/compaction.c | 15 ++++++++++++---
>> 2 files changed, 13 insertions(+), 3 deletions(-)
>>
> [...]
>> @@ -1631,7 +1639,8 @@ enum compact_result try_to_compact_pages(gfp_t gfp_mask, unsigned int order,
>> ac->nodemask) {
>> enum compact_result status;
>>
>> - if (compaction_deferred(zone, order)) {
>> + if (prio > COMPACT_PRIO_SYNC_FULL
>> + && compaction_deferred(zone, order)) {
>> rc = max_t(enum compact_result, COMPACT_DEFERRED, rc);
>> continue;
>> }
>
> Wouldn't it be better to pull the prio check into compaction_deferred
> directly? There are more callers and I am not really sure all of them
> would behave consistently.
I'll check, thanks.
next prev parent reply other threads:[~2016-05-16 7:17 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 [this message]
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
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
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=573973F7.7070202@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.