From: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Rik van Riel <riel@redhat.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Mel Gorman <mel@csn.ul.ie>,
Andrew Morton <akpm@linux-foundation.org>,
jaschut@sandia.gov, minchan@kernel.org
Subject: Re: [PATCH -mm v2] mm: have order > 0 compaction start off where it left
Date: Sat, 30 Jun 2012 12:51:00 +0900 [thread overview]
Message-ID: <4FEE77A4.2000302@jp.fujitsu.com> (raw)
In-Reply-To: <20120628135520.0c48b066@annuminas.surriel.com>
(2012/06/29 2:55), Rik van Riel wrote:
> Order > 0 compaction stops when enough free pages of the correct
> page order have been coalesced. When doing subsequent higher order
> allocations, it is possible for compaction to be invoked many times.
>
> However, the compaction code always starts out looking for things to
> compact at the start of the zone, and for free pages to compact things
> to at the end of the zone.
>
> This can cause quadratic behaviour, with isolate_freepages starting
> at the end of the zone each time, even though previous invocations
> of the compaction code already filled up all free memory on that end
> of the zone.
>
> This can cause isolate_freepages to take enormous amounts of CPU
> with certain workloads on larger memory systems.
>
> The obvious solution is to have isolate_freepages remember where
> it left off last time, and continue at that point the next time
> it gets invoked for an order > 0 compaction. This could cause
> compaction to fail if cc->free_pfn and cc->migrate_pfn are close
> together initially, in that case we restart from the end of the
> zone and try once more.
>
> Forced full (order == -1) compactions are left alone.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Mel Gorman <mel@csn.ul.ie>
> Reported-by: Jim Schutt <jaschut@sandia.gov>
> Signed-off-by: Rik van Riel <riel@redhat.com>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
--
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: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Rik van Riel <riel@redhat.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Mel Gorman <mel@csn.ul.ie>,
Andrew Morton <akpm@linux-foundation.org>,
jaschut@sandia.gov, minchan@kernel.org
Subject: Re: [PATCH -mm v2] mm: have order > 0 compaction start off where it left
Date: Sat, 30 Jun 2012 12:51:00 +0900 [thread overview]
Message-ID: <4FEE77A4.2000302@jp.fujitsu.com> (raw)
In-Reply-To: <20120628135520.0c48b066@annuminas.surriel.com>
(2012/06/29 2:55), Rik van Riel wrote:
> Order > 0 compaction stops when enough free pages of the correct
> page order have been coalesced. When doing subsequent higher order
> allocations, it is possible for compaction to be invoked many times.
>
> However, the compaction code always starts out looking for things to
> compact at the start of the zone, and for free pages to compact things
> to at the end of the zone.
>
> This can cause quadratic behaviour, with isolate_freepages starting
> at the end of the zone each time, even though previous invocations
> of the compaction code already filled up all free memory on that end
> of the zone.
>
> This can cause isolate_freepages to take enormous amounts of CPU
> with certain workloads on larger memory systems.
>
> The obvious solution is to have isolate_freepages remember where
> it left off last time, and continue at that point the next time
> it gets invoked for an order > 0 compaction. This could cause
> compaction to fail if cc->free_pfn and cc->migrate_pfn are close
> together initially, in that case we restart from the end of the
> zone and try once more.
>
> Forced full (order == -1) compactions are left alone.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Mel Gorman <mel@csn.ul.ie>
> Reported-by: Jim Schutt <jaschut@sandia.gov>
> Signed-off-by: Rik van Riel <riel@redhat.com>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
next prev parent reply other threads:[~2012-06-30 3:53 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-28 17:55 [PATCH -mm v2] mm: have order > 0 compaction start off where it left Rik van Riel
2012-06-28 17:55 ` Rik van Riel
2012-06-28 20:19 ` Jim Schutt
2012-06-28 20:19 ` Jim Schutt
2012-06-28 20:57 ` Rik van Riel
2012-06-28 20:57 ` Rik van Riel
2012-06-28 20:59 ` Andrew Morton
2012-06-28 20:59 ` Andrew Morton
2012-06-28 21:24 ` Rik van Riel
2012-06-28 21:24 ` Rik van Riel
2012-06-28 21:35 ` Andrew Morton
2012-06-28 21:35 ` Andrew Morton
2012-07-02 17:42 ` Sasha Levin
2012-07-02 17:42 ` Sasha Levin
2012-07-03 0:57 ` Rik van Riel
2012-07-03 0:57 ` Rik van Riel
2012-07-03 2:54 ` Minchan Kim
2012-07-03 2:54 ` Minchan Kim
2012-07-03 10:10 ` Mel Gorman
2012-07-03 10:10 ` Mel Gorman
2012-07-03 21:48 ` Andrew Morton
2012-07-03 21:48 ` Andrew Morton
2012-07-04 2:34 ` Minchan Kim
2012-07-04 2:34 ` Minchan Kim
2012-07-04 7:42 ` Andrew Morton
2012-07-04 7:42 ` Andrew Morton
2012-07-04 8:01 ` Minchan Kim
2012-07-04 8:01 ` Minchan Kim
2012-07-11 20:18 ` [PATCH -mm v3] " Rik van Riel
2012-07-11 20:18 ` Rik van Riel
2012-07-12 2:26 ` Minchan Kim
2012-07-12 2:26 ` Minchan Kim
2012-07-04 9:57 ` [PATCH -mm v2] " Mel Gorman
2012-07-04 9:57 ` Mel Gorman
2012-06-28 23:27 ` Minchan Kim
2012-06-28 23:27 ` Minchan Kim
2012-07-03 14:59 ` Rik van Riel
2012-07-03 14:59 ` Rik van Riel
2012-07-04 2:28 ` Minchan Kim
2012-07-04 2:28 ` Minchan Kim
2012-07-04 10:08 ` Mel Gorman
2012-07-04 10:08 ` Mel Gorman
2012-07-03 20:13 ` [PATCH -mm] mm: minor fixes for compaction Rik van Riel
2012-07-03 20:13 ` Rik van Riel
2012-07-04 2:36 ` Minchan Kim
2012-07-04 2:36 ` Minchan Kim
2012-06-29 10:02 ` [PATCH -mm v2] mm: have order > 0 compaction start off where it left Mel Gorman
2012-06-29 10:02 ` Mel Gorman
2012-06-30 3:51 ` Kamezawa Hiroyuki [this message]
2012-06-30 3:51 ` Kamezawa Hiroyuki
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=4FEE77A4.2000302@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=jaschut@sandia.gov \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=minchan@kernel.org \
--cc=riel@redhat.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.