From: Vlastimil Babka <vbabka@suse.cz>
To: Joonsoo Kim <js1304@gmail.com>
Cc: Mel Gorman <mgorman@suse.de>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Rik van Riel <riel@redhat.com>,
David Rientjes <rientjes@google.com>,
Minchan Kim <minchan@kernel.org>
Subject: Re: [RFC PATCH 00/10] redesign compaction algorithm
Date: Fri, 26 Jun 2015 13:22:07 +0200 [thread overview]
Message-ID: <558D35DF.8080008@suse.cz> (raw)
In-Reply-To: <CAAmzW4P0H2dxVa9zMBkKEyX-R3at-xo-pBLMS07j=svQzYwvBQ@mail.gmail.com>
On 06/26/2015 04:14 AM, Joonsoo Kim wrote:
> 2015-06-26 3:56 GMT+09:00 Vlastimil Babka <vbabka@suse.cz>:
>>> on non-movable would be maintained so fallback doesn't happen.
>>
>> There's nothing that guarantees that the migration scanner will be emptying
>> unmovable pageblock, or am I missing something?
>
> As replied to Mel's comment, as number of unmovable pageblocks, which is
> filled by movable pages due to this compaction change increases,
> possible candidate reclaimable/migratable pages from them also increase.
> So, at some time, amount of used page by free scanner and amount of
> migrated page by migration scanner would be balanced.
>
>> Worse, those pageblocks would be
>> marked to skip by the free scanner if it isolated free pages from them, so
>> migration scanner would skip them.
>
> Yes, but, next iteration will move out movable pages from that pageblock
> and freed pages will be used for further unmovable allocation.
> So, in the long term, this doesn't make much more fragmentation.
Theoretically, maybe. I guess there's not much point discussing it
further, until there's data from experiments evaluating the long-term
fragmentation (think of e.g. the number of mixed pageblocks you already
checked in different experiments).
> 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: Joonsoo Kim <js1304@gmail.com>
Cc: Mel Gorman <mgorman@suse.de>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Rik van Riel <riel@redhat.com>,
David Rientjes <rientjes@google.com>,
Minchan Kim <minchan@kernel.org>
Subject: Re: [RFC PATCH 00/10] redesign compaction algorithm
Date: Fri, 26 Jun 2015 13:22:07 +0200 [thread overview]
Message-ID: <558D35DF.8080008@suse.cz> (raw)
In-Reply-To: <CAAmzW4P0H2dxVa9zMBkKEyX-R3at-xo-pBLMS07j=svQzYwvBQ@mail.gmail.com>
On 06/26/2015 04:14 AM, Joonsoo Kim wrote:
> 2015-06-26 3:56 GMT+09:00 Vlastimil Babka <vbabka@suse.cz>:
>>> on non-movable would be maintained so fallback doesn't happen.
>>
>> There's nothing that guarantees that the migration scanner will be emptying
>> unmovable pageblock, or am I missing something?
>
> As replied to Mel's comment, as number of unmovable pageblocks, which is
> filled by movable pages due to this compaction change increases,
> possible candidate reclaimable/migratable pages from them also increase.
> So, at some time, amount of used page by free scanner and amount of
> migrated page by migration scanner would be balanced.
>
>> Worse, those pageblocks would be
>> marked to skip by the free scanner if it isolated free pages from them, so
>> migration scanner would skip them.
>
> Yes, but, next iteration will move out movable pages from that pageblock
> and freed pages will be used for further unmovable allocation.
> So, in the long term, this doesn't make much more fragmentation.
Theoretically, maybe. I guess there's not much point discussing it
further, until there's data from experiments evaluating the long-term
fragmentation (think of e.g. the number of mixed pageblocks you already
checked in different experiments).
> Thanks.
>
next prev parent reply other threads:[~2015-06-26 11:22 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-25 0:45 [RFC PATCH 00/10] redesign compaction algorithm Joonsoo Kim
2015-06-25 0:45 ` Joonsoo Kim
2015-06-25 0:45 ` [RFC PATCH 01/10] mm/compaction: update skip-bit if whole pageblock is really scanned Joonsoo Kim
2015-06-25 0:45 ` Joonsoo Kim
2015-06-25 0:45 ` [RFC PATCH 02/10] mm/compaction: skip useless pfn for scanner's cached pfn Joonsoo Kim
2015-06-25 0:45 ` Joonsoo Kim
2015-06-25 0:45 ` [RFC PATCH 03/10] mm/compaction: always update " Joonsoo Kim
2015-06-25 0:45 ` Joonsoo Kim
2015-06-25 9:08 ` Vlastimil Babka
2015-06-25 9:08 ` Vlastimil Babka
2015-06-25 0:45 ` [RFC PATCH 04/10] mm/compaction: clean-up restarting condition check Joonsoo Kim
2015-06-25 0:45 ` Joonsoo Kim
2015-06-25 0:45 ` [RFC PATCH 05/10] mm/compaction: make freepage scanner scans non-movable pageblock Joonsoo Kim
2015-06-25 0:45 ` Joonsoo Kim
2015-06-25 0:45 ` [RFC PATCH 06/10] mm/compaction: introduce compaction depleted state on zone Joonsoo Kim
2015-06-25 0:45 ` Joonsoo Kim
2015-06-25 0:45 ` [RFC PATCH 07/10] mm/compaction: limit compaction activity in compaction depleted state Joonsoo Kim
2015-06-25 0:45 ` Joonsoo Kim
2015-06-25 0:45 ` [RFC PATCH 08/10] mm/compaction: remove compaction deferring Joonsoo Kim
2015-06-25 0:45 ` Joonsoo Kim
2015-06-25 0:45 ` [RFC PATCH 09/10] mm/compaction: redesign compaction Joonsoo Kim
2015-06-25 0:45 ` Joonsoo Kim
2015-06-25 0:45 ` [RFC PATCH 10/10] mm/compaction: new threshold for compaction depleted zone Joonsoo Kim
2015-06-25 0:45 ` Joonsoo Kim
2015-06-25 11:03 ` [RFC PATCH 00/10] redesign compaction algorithm Mel Gorman
2015-06-25 11:03 ` Mel Gorman
2015-06-25 17:11 ` Joonsoo Kim
2015-06-25 17:11 ` Joonsoo Kim
2015-06-25 17:25 ` Mel Gorman
2015-06-25 17:25 ` Mel Gorman
2015-06-25 18:14 ` Joonsoo Kim
2015-06-25 18:14 ` Joonsoo Kim
2015-06-25 18:41 ` Mel Gorman
2015-06-25 18:41 ` Mel Gorman
2015-06-26 2:07 ` Joonsoo Kim
2015-06-26 2:07 ` Joonsoo Kim
2015-06-26 10:22 ` Mel Gorman
2015-06-26 10:22 ` Mel Gorman
2015-07-08 8:24 ` Joonsoo Kim
2015-07-08 8:24 ` Joonsoo Kim
2015-07-21 9:27 ` Vlastimil Babka
2015-07-21 9:27 ` Vlastimil Babka
2015-07-23 5:33 ` Joonsoo Kim
2015-07-23 5:33 ` Joonsoo Kim
2015-06-25 18:56 ` Vlastimil Babka
2015-06-25 18:56 ` Vlastimil Babka
2015-06-26 2:14 ` Joonsoo Kim
2015-06-26 2:14 ` Joonsoo Kim
2015-06-26 11:22 ` Vlastimil Babka [this message]
2015-06-26 11:22 ` Vlastimil Babka
2015-06-25 13:35 ` Vlastimil Babka
2015-06-25 13:35 ` Vlastimil Babka
2015-06-25 17:32 ` Joonsoo Kim
2015-06-25 17:32 ` 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=558D35DF.8080008@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=js1304@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=minchan@kernel.org \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
/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.