linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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 15:42:21 +0200	[thread overview]
Message-ID: <570BA9BD.2030404@suse.cz> (raw)
In-Reply-To: <20160411132745.GH23157@dhcp22.suse.cz>

On 04/11/2016 03:27 PM, Michal Hocko wrote:
> On Mon 11-04-16 14:53:36, Vlastimil Babka wrote:
>> On 04/11/2016 02:46 PM, Michal Hocko wrote:
>>
>> 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.
>
> I am not really sure I understand. The primary intention of this patch
> is to distinguish where we have scanned basically whole zones from cases
> where a new scan started off previous mark and so it was just unlucky to
> see only tiny bit of the zone where we would clearly give up too early.
> FWIU this shouldn't be the case if we start scanning from the beginning
> of the zone even if we raced on the other end of the zone because the
> missed part would be negligible. Is that understanding correct?

Yes, it should be less unlucky than seeing a tiny bit of the zone. Just 
wanted to point out that you might still not see the whole zone in one 
compaction attempt. E.g. async compaction is first, advances the free 
scanner and caches its position when it bails out due to being 
contended. Then direct reclaim frees some pages behind the cached 
position. Sync compaction attempts starts migration scanner from 
start_pfn, but picks up the cached free scanner pfn. The result is 
missing some free pages and the scanners meeting somewhat earlier than 
they otherwise would. Probably not critical even for OOM decisions, as 
that's also racy anyway.

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

  reply	other threads:[~2016-04-11 13:42 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
2016-04-11 13:27         ` Michal Hocko
2016-04-11 13:42           ` Vlastimil Babka [this message]
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=570BA9BD.2030404@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;
as well as URLs for NNTP newsgroup(s).