From: Vlastimil Babka <vbabka@suse.cz>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Mel Gorman <mgorman@suse.de>,
David Rientjes <rientjes@google.com>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Joonsoo Kim <js1304@gmail.com>,
Hillf Danton <hillf.zj@alibaba-inc.com>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 06/11] mm, compaction: distinguish between full and partial COMPACT_COMPLETE
Date: Mon, 11 Apr 2016 14:53:36 +0200 [thread overview]
Message-ID: <570B9E50.9040000@suse.cz> (raw)
In-Reply-To: <20160411124653.GG23157@dhcp22.suse.cz>
On 04/11/2016 02:46 PM, Michal Hocko wrote:
>> This assumes that migrate scanner at initial position implies also free
>> scanner at the initial position. That should be true, because migration
>> scanner is the first to run. But getting the zone->compact_cached_*_pfn is
>> racy. Worse, zone->compact_cached_migrate_pfn is array distinguishing sync
>> and async compaction, so it's possible that async compaction has advanced
>> both its own migrate scanner cached position, and the shared free scanner
>> cached position, and then sync compaction starts migrate scanner at
>> start_pfn, but free scanner has already advanced.
>
> OK, I see. The whole thing smelled racy but I thought it wouldn't be
> such a big deal. Even if we raced then only a marginal part of the zone
> wouldn't be scanned, right? Or is it possible that free_pfn would appear
> in the middle of the zone because of the race?
The racy part is negligible but I didn't realize the sync/async migrate
scanner part until now. So yeah, free_pfn could have got to middle of
zone when it was in the async mode. But that also means that the async
mode recently used up all free pages in the second half of the zone. WRT
free pages isolation, async mode is not trying less than sync, so it
shouldn't be a considerable missed opportunity if we don't rescan the
it, though.
>> So you might still see a false positive COMPACT_COMPLETE, just less
>> frequently and probably with much lower impact.
>> But if you need to be truly reliable, check also that cc->free_pfn ==
>> round_down(end_pfn - 1, pageblock_nr_pages)
>
> I do not think we need the precise check if the race window (in the
> skipped zone range) is always small.
>
> 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>
next prev parent reply other threads:[~2016-04-11 12:53 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-05 11:25 [PATCH 00/11] oom detection rework v5 Michal Hocko
2016-04-05 11:25 ` [PATCH 01/11] mm, oom: rework oom detection Michal Hocko
2016-04-05 11:25 ` [PATCH 02/11] mm: throttle on IO only when there are too many dirty and writeback pages Michal Hocko
2016-04-05 11:25 ` [PATCH 03/11] mm, compaction: change COMPACT_ constants into enum Michal Hocko
2016-04-05 11:25 ` [PATCH 04/11] mm, compaction: cover all compaction mode in compact_zone Michal Hocko
2016-04-05 11:25 ` [PATCH 05/11] mm, compaction: distinguish COMPACT_DEFERRED from COMPACT_SKIPPED Michal Hocko
2016-04-11 11:02 ` Vlastimil Babka
2016-04-11 11:24 ` Michal Hocko
2016-04-05 11:25 ` [PATCH 06/11] mm, compaction: distinguish between full and partial COMPACT_COMPLETE Michal Hocko
2016-04-11 12:10 ` Vlastimil Babka
2016-04-11 12:46 ` Michal Hocko
2016-04-11 12:53 ` Vlastimil Babka [this message]
2016-04-11 13:27 ` Michal Hocko
2016-04-11 13:42 ` Vlastimil Babka
2016-04-11 13:46 ` Michal Hocko
2016-04-05 11:25 ` [PATCH 07/11] mm, compaction: Update compaction_result ordering Michal Hocko
2016-04-11 12:16 ` Vlastimil Babka
2016-04-05 11:25 ` [PATCH 08/11] mm, compaction: Simplify __alloc_pages_direct_compact feedback interface Michal Hocko
2016-04-11 13:48 ` Vlastimil Babka
2016-04-05 11:25 ` [PATCH 09/11] mm, compaction: Abstract compaction feedback to helpers Michal Hocko
2016-04-05 23:58 ` Andrew Morton
2016-04-06 0:55 ` Hugh Dickins
2016-04-06 9:26 ` Michal Hocko
2016-04-06 17:46 ` Andrew Morton
2016-04-11 14:39 ` Vlastimil Babka
2016-04-11 15:14 ` Michal Hocko
2016-04-11 15:33 ` Michal Hocko
2016-04-12 11:53 ` Vlastimil Babka
2016-04-12 12:23 ` Michal Hocko
2016-04-11 15:40 ` Michal Hocko
2016-04-11 16:07 ` [RFC PATCH] mm: use compaction feedback for thp backoff conditions Michal Hocko
2016-04-12 11:54 ` [PATCH 09/11] mm, compaction: Abstract compaction feedback to helpers Vlastimil Babka
2016-04-05 11:25 ` [PATCH 10/11] mm, oom: protect !costly allocations some more Michal Hocko
2016-04-06 0:06 ` Andrew Morton
2016-04-06 9:28 ` Michal Hocko
2016-04-11 14:48 ` Vlastimil Babka
2016-04-05 11:25 ` [PATCH 11/11] mm: consider compaction feedback also for costly allocation Michal Hocko
2016-04-05 12:46 ` Michal Hocko
2016-04-11 15:07 ` Vlastimil Babka
2016-04-05 12:47 ` [PATCH 00/11] oom detection rework v5 Michal Hocko
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=570B9E50.9040000@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=hillf.zj@alibaba-inc.com \
--cc=js1304@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--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