From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Minchan Kim <minchan@kernel.org>, Mel Gorman <mgorman@suse.de>,
Michal Nazarewicz <mina86@mina86.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Christoph Lameter <cl@linux.com>, Rik van Riel <riel@redhat.com>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 4/5] mm, compaction: always update cached scanner positions
Date: Mon, 27 Oct 2014 16:35:22 +0900 [thread overview]
Message-ID: <20141027073522.GB23379@js1304-P5Q-DELUXE> (raw)
In-Reply-To: <1412696019-21761-5-git-send-email-vbabka@suse.cz>
On Tue, Oct 07, 2014 at 05:33:38PM +0200, Vlastimil Babka wrote:
> Compaction caches the migration and free scanner positions between compaction
> invocations, so that the whole zone gets eventually scanned and there is no
> bias towards the initial scanner positions at the beginning/end of the zone.
>
> The cached positions are continuously updated as scanners progress and the
> updating stops as soon as a page is successfully isolated. The reasoning
> behind this is that a pageblock where isolation succeeded is likely to succeed
> again in near future and it should be worth revisiting it.
>
> However, the downside is that potentially many pages are rescanned without
> successful isolation. At worst, there might be a page where isolation from LRU
> succeeds but migration fails (potentially always). So upon encountering this
> page, cached position would always stop being updated for no good reason.
> It might have been useful to let such page be rescanned with sync compaction
> after async one failed, but this is now handled by caching scanner position
> for async and sync mode separately since commit 35979ef33931 ("mm, compaction:
> add per-zone migration pfn cache for async compaction").
Hmm... I'm not sure that this patch is good thing.
In asynchronous compaction, compaction could be easily failed and
isolated freepages are returned to the buddy. In this case, next
asynchronous compaction would skip those returned freepages and
both scanners could meet prematurely.
And, I guess that pageblock skip feature effectively disable pageblock
rescanning if there is no freepage during rescan. This patch would
eliminate effect of pageblock skip feature.
IIUC, compaction logic assume that there are many temporary failure
conditions. Retrying from others would reduce effect of this temporary
failure so implementation looks as is.
If what we want is scanning each page once in each epoch, we can
implement compaction logic differently.
Please let me know if I'm missing something.
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:[~2014-10-27 7:34 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-07 15:33 [PATCH 0/5] Further compaction tuning Vlastimil Babka
2014-10-07 15:33 ` [PATCH 1/5] mm, compaction: pass classzone_idx and alloc_flags to watermark checking Vlastimil Babka
2014-10-20 15:45 ` Rik van Riel
2014-10-27 6:46 ` Joonsoo Kim
2014-10-27 9:11 ` Vlastimil Babka
2014-10-28 7:16 ` Joonsoo Kim
2014-10-29 13:51 ` Vlastimil Babka
2014-10-31 7:49 ` Joonsoo Kim
2014-11-14 8:52 ` Vlastimil Babka
2014-10-07 15:33 ` [PATCH 2/5] mm, compaction: simplify deferred compaction Vlastimil Babka
2014-10-15 22:32 ` Andrew Morton
2014-10-16 15:11 ` Vlastimil Babka
2014-10-07 15:33 ` [PATCH 3/5] mm, compaction: defer only on COMPACT_COMPLETE Vlastimil Babka
2014-10-20 15:18 ` Rik van Riel
2014-10-07 15:33 ` [PATCH 4/5] mm, compaction: always update cached scanner positions Vlastimil Babka
2014-10-20 15:26 ` Rik van Riel
2014-10-27 7:35 ` Joonsoo Kim [this message]
2014-10-27 9:39 ` Vlastimil Babka
2014-10-28 7:08 ` Joonsoo Kim
2014-10-31 15:53 ` Vlastimil Babka
2014-11-04 0:28 ` Joonsoo Kim
2014-11-14 8:57 ` Vlastimil Babka
2014-10-07 15:33 ` [PATCH 5/5] mm, compaction: more focused lru and pcplists draining Vlastimil Babka
2014-10-20 15:44 ` Rik van Riel
2014-10-27 7:41 ` Joonsoo Kim
2014-11-03 8:12 ` Vlastimil Babka
2014-11-04 0:37 ` Joonsoo Kim
2014-11-13 12:47 ` Vlastimil Babka
2014-11-14 7:05 ` Joonsoo Kim
2014-11-19 22:53 ` 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=20141027073522.GB23379@js1304-P5Q-DELUXE \
--to=iamjoonsoo.kim@lge.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mina86@mina86.com \
--cc=minchan@kernel.org \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
/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