From: Joonsoo Kim <js1304@gmail.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
LKML <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 6/6] mm, compaction: decouple updating pageblock_skip and cached pfn
Date: Tue, 16 Jun 2015 22:03:13 +0900 [thread overview]
Message-ID: <CAAmzW4MxDd0V6SckhFk7E9rwByQPkjzJzGBKSerjYsj41B7dhQ@mail.gmail.com> (raw)
In-Reply-To: <5580177F.6070303@suse.cz>
2015-06-16 21:33 GMT+09:00 Vlastimil Babka <vbabka@suse.cz>:
> On 06/16/2015 08:10 AM, Joonsoo Kim wrote:
>> On Wed, Jun 10, 2015 at 11:32:34AM +0200, Vlastimil Babka wrote:
>>> The pageblock_skip bitmap and cached scanner pfn's are two mechanisms in
>>> compaction to prevent rescanning pages where isolation has recently failed
>>> or they were scanned during the previous compaction attempt.
>>>
>>> Currently, both kinds of information are updated via update_pageblock_skip(),
>>> which is suboptimal for the cached scanner pfn's:
>>>
>>> - The condition "isolation has failed in the pageblock" checked by
>>> update_pageblock_skip() may be valid for the pageblock_skip bitmap, but makes
>>> less sense for cached pfn's. There's little point for the next compaction
>>> attempt to scan again a pageblock where all pages that could be isolated were
>>> already processed.
>>
>> In async compaction, compaction could be stopped due to cc->contended
>> in freepage scanner so sometimes isolated pages were not migrated. Your
>> change makes next async compaction skip these pages. This possibly causes
>> compaction complete prematurely by async compaction.
>
> Hm, I see, thanks. That could be fixed when returning the non-migrated pages,
> just like we do for the unused freepages and cached free scanner position.
Yes, that would work.
>> And, rescan previous attempted range could solve some race problem.
>> If allocated page waits to set PageLRU in pagevec, compaction will
>> pass it. If we try rescan after short time, page will have PageLRU and
>> compaction can isolate and migrate it and make high order freepage. This
>> requires some rescanning overhead but migration overhead which is more bigger
>> than scanning overhead is just a little. If compaction pass it like as
>> this change, pages on this area would be allocated for other requestor, and,
>> when compaction revisit, there would be more page to migrate.
>
> The same "race problem" (and many others) can happen when we don't abort and
> later restart from cached pfn's, but just continue on to later pageblocks within
> single compaction run. Still I would expect that it's statistically higher
> chance to succeed in the next pageblock than rescanning pageblock(s) that we
> just scanned.
If we consider just one compaction attempt, yes, scanning next pageblock
is more promising way to succeed. But, if we rescan pageblock that we
just scanned and, fortunately, we succeed to migrate and make high order
freeepage from that pageblock, more compaction attempt can be successful
before both scanner meet and this may result in less overhead in view of
overall compaction attempts.
>> I basically agree with this change because it is more intuitive. But,
>> I'd like to see some improvement result or test this patch myself before merging
>> it.
>
> Sure, please test. I don't expect much difference, the primary motivation was
> really that the recorded pfn's by tracepoints looked much saner.
Yes. that's what I'd like to say from *intuitive*. :)
Thanks.
WARNING: multiple messages have this Message-ID (diff)
From: Joonsoo Kim <js1304@gmail.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
LKML <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 6/6] mm, compaction: decouple updating pageblock_skip and cached pfn
Date: Tue, 16 Jun 2015 22:03:13 +0900 [thread overview]
Message-ID: <CAAmzW4MxDd0V6SckhFk7E9rwByQPkjzJzGBKSerjYsj41B7dhQ@mail.gmail.com> (raw)
In-Reply-To: <5580177F.6070303@suse.cz>
2015-06-16 21:33 GMT+09:00 Vlastimil Babka <vbabka@suse.cz>:
> On 06/16/2015 08:10 AM, Joonsoo Kim wrote:
>> On Wed, Jun 10, 2015 at 11:32:34AM +0200, Vlastimil Babka wrote:
>>> The pageblock_skip bitmap and cached scanner pfn's are two mechanisms in
>>> compaction to prevent rescanning pages where isolation has recently failed
>>> or they were scanned during the previous compaction attempt.
>>>
>>> Currently, both kinds of information are updated via update_pageblock_skip(),
>>> which is suboptimal for the cached scanner pfn's:
>>>
>>> - The condition "isolation has failed in the pageblock" checked by
>>> update_pageblock_skip() may be valid for the pageblock_skip bitmap, but makes
>>> less sense for cached pfn's. There's little point for the next compaction
>>> attempt to scan again a pageblock where all pages that could be isolated were
>>> already processed.
>>
>> In async compaction, compaction could be stopped due to cc->contended
>> in freepage scanner so sometimes isolated pages were not migrated. Your
>> change makes next async compaction skip these pages. This possibly causes
>> compaction complete prematurely by async compaction.
>
> Hm, I see, thanks. That could be fixed when returning the non-migrated pages,
> just like we do for the unused freepages and cached free scanner position.
Yes, that would work.
>> And, rescan previous attempted range could solve some race problem.
>> If allocated page waits to set PageLRU in pagevec, compaction will
>> pass it. If we try rescan after short time, page will have PageLRU and
>> compaction can isolate and migrate it and make high order freepage. This
>> requires some rescanning overhead but migration overhead which is more bigger
>> than scanning overhead is just a little. If compaction pass it like as
>> this change, pages on this area would be allocated for other requestor, and,
>> when compaction revisit, there would be more page to migrate.
>
> The same "race problem" (and many others) can happen when we don't abort and
> later restart from cached pfn's, but just continue on to later pageblocks within
> single compaction run. Still I would expect that it's statistically higher
> chance to succeed in the next pageblock than rescanning pageblock(s) that we
> just scanned.
If we consider just one compaction attempt, yes, scanning next pageblock
is more promising way to succeed. But, if we rescan pageblock that we
just scanned and, fortunately, we succeed to migrate and make high order
freeepage from that pageblock, more compaction attempt can be successful
before both scanner meet and this may result in less overhead in view of
overall compaction attempts.
>> I basically agree with this change because it is more intuitive. But,
>> I'd like to see some improvement result or test this patch myself before merging
>> it.
>
> Sure, please test. I don't expect much difference, the primary motivation was
> really that the recorded pfn's by tracepoints looked much saner.
Yes. that's what I'd like to say from *intuitive*. :)
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:[~2015-06-16 13:03 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-10 9:32 [PATCH 0/6] Assorted compaction cleanups and optimizations Vlastimil Babka
2015-06-10 9:32 ` Vlastimil Babka
2015-06-10 9:32 ` [PATCH 1/6] mm, compaction: more robust check for scanners meeting Vlastimil Babka
2015-06-10 9:32 ` Vlastimil Babka
2015-06-10 18:02 ` Rik van Riel
2015-06-10 18:02 ` Rik van Riel
2015-06-12 9:55 ` Michal Nazarewicz
2015-06-12 9:55 ` Michal Nazarewicz
2015-06-16 5:37 ` Joonsoo Kim
2015-06-16 5:37 ` Joonsoo Kim
2015-06-19 13:41 ` Mel Gorman
2015-06-19 13:41 ` Mel Gorman
2015-06-10 9:32 ` [PATCH 2/6] mm, compaction: simplify handling restart position in free pages scanner Vlastimil Babka
2015-06-10 9:32 ` Vlastimil Babka
2015-06-16 5:38 ` Joonsoo Kim
2015-06-16 5:38 ` Joonsoo Kim
2015-06-19 13:48 ` Mel Gorman
2015-06-19 13:48 ` Mel Gorman
2015-06-10 9:32 ` [PATCH 3/6] mm, compaction: encapsulate resetting cached scanner positions Vlastimil Babka
2015-06-10 9:32 ` Vlastimil Babka
2015-06-12 10:07 ` Michal Nazarewicz
2015-06-12 10:07 ` Michal Nazarewicz
2015-06-16 5:41 ` Joonsoo Kim
2015-06-16 5:41 ` Joonsoo Kim
2015-06-16 12:13 ` Vlastimil Babka
2015-06-16 12:13 ` Vlastimil Babka
2015-06-10 9:32 ` [PATCH 4/6] mm, compaction: always skip compound pages by order in migrate scanner Vlastimil Babka
2015-06-10 9:32 ` Vlastimil Babka
2015-06-12 10:11 ` Michal Nazarewicz
2015-06-12 10:11 ` Michal Nazarewicz
2015-06-16 5:44 ` Joonsoo Kim
2015-06-16 5:44 ` Joonsoo Kim
2015-06-16 12:16 ` Vlastimil Babka
2015-06-16 12:16 ` Vlastimil Babka
2015-06-19 13:58 ` Mel Gorman
2015-06-19 13:58 ` Mel Gorman
2015-06-10 9:32 ` [PATCH 5/6] mm, compaction: skip compound pages by order in free scanner Vlastimil Babka
2015-06-10 9:32 ` Vlastimil Babka
2015-06-12 10:18 ` Michal Nazarewicz
2015-06-12 10:18 ` Michal Nazarewicz
2015-06-16 5:45 ` Joonsoo Kim
2015-06-16 5:45 ` Joonsoo Kim
2015-06-10 9:32 ` [PATCH 6/6] mm, compaction: decouple updating pageblock_skip and cached pfn Vlastimil Babka
2015-06-10 9:32 ` Vlastimil Babka
2015-06-16 6:10 ` Joonsoo Kim
2015-06-16 6:10 ` Joonsoo Kim
2015-06-16 12:33 ` Vlastimil Babka
2015-06-16 12:33 ` Vlastimil Babka
2015-06-16 13:03 ` Joonsoo Kim [this message]
2015-06-16 13:03 ` Joonsoo Kim
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=CAAmzW4MxDd0V6SckhFk7E9rwByQPkjzJzGBKSerjYsj41B7dhQ@mail.gmail.com \
--to=js1304@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.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 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.