All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	Adam Litke <agl@us.ibm.com>, Avi Kivity <avi@redhat.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC-PATCH 0/7] Memory Compaction v1
Date: Thu, 21 Jan 2010 10:11:12 +0000	[thread overview]
Message-ID: <20100121101112.GH5154@csn.ul.ie> (raw)
In-Reply-To: <20100121115636.73BA.A69D9226@jp.fujitsu.com>

On Thu, Jan 21, 2010 at 12:12:11PM +0900, KOSAKI Motohiro wrote:
> Hi Mel,
> 
> Sorry, I haven't read this patch at all.
> 
> > The time differences are marginal but bear in mind that this is an ideal
> > case of mostly unmapped buffer pages. On nice set of results is between
> > allocations 13-18 where no pages were reclaimed, some compaction occured
> > and 300 huge pages were allocated in 0.16 seconds. Furthermore, compaction
> > allocated a high higher percentage of memory (91% of RAM as huge pages).
> > 
> > The downside appears to be that the compaction kernel reclaimed even more
> > pages than the vanilla kernel. However, take the cut-off point of 880 pages
> > that both kernels succeeded. The vanilla kernel had reclaimed 105132 pages
> > at that point. The kernel with compaction had reclaimed 59071, less than
> > half of what the vanilla kernel reclaimed. i.e. the bulk of pages reclaimed
> > with the compaction kernel were to get from 87% of memory allocated to 91%
> > as huge pages.
> > 
> > These results would appear to be an encouraging enough start.
> > 
> > Comments?
> 
> I think "Total pages reclaimed" increasing is not good thing ;)

First, I made a mistake in the patch. With the bug fixed, they're
reduced. See the post later in the thread
http://lkml.org/lkml/2010/1/6/215

> Honestly, I haven't understand why your patch increase reclaimed and
> the exactly meaning of the your tool's rclm field.
> 
> Can you share your mesurement script? May I run the same test?
> 

Unfortunately at the moment it's part of a mini-testgrid setup I run out
of the house. It doesn't lend itself to being stand-alone. I'll break it
out as part of the next release.

> I like this patch, but I don't like increasing reclaim. I'd like to know
> this patch require any vmscan change and/or its change mitigate the issue.
> 

With the bug repaired, reclaims go from 105132 to 45935 with more huge
pages allocated so right now, no special action is required.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mel@csn.ul.ie>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	Adam Litke <agl@us.ibm.com>, Avi Kivity <avi@redhat.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC-PATCH 0/7] Memory Compaction v1
Date: Thu, 21 Jan 2010 10:11:12 +0000	[thread overview]
Message-ID: <20100121101112.GH5154@csn.ul.ie> (raw)
In-Reply-To: <20100121115636.73BA.A69D9226@jp.fujitsu.com>

On Thu, Jan 21, 2010 at 12:12:11PM +0900, KOSAKI Motohiro wrote:
> Hi Mel,
> 
> Sorry, I haven't read this patch at all.
> 
> > The time differences are marginal but bear in mind that this is an ideal
> > case of mostly unmapped buffer pages. On nice set of results is between
> > allocations 13-18 where no pages were reclaimed, some compaction occured
> > and 300 huge pages were allocated in 0.16 seconds. Furthermore, compaction
> > allocated a high higher percentage of memory (91% of RAM as huge pages).
> > 
> > The downside appears to be that the compaction kernel reclaimed even more
> > pages than the vanilla kernel. However, take the cut-off point of 880 pages
> > that both kernels succeeded. The vanilla kernel had reclaimed 105132 pages
> > at that point. The kernel with compaction had reclaimed 59071, less than
> > half of what the vanilla kernel reclaimed. i.e. the bulk of pages reclaimed
> > with the compaction kernel were to get from 87% of memory allocated to 91%
> > as huge pages.
> > 
> > These results would appear to be an encouraging enough start.
> > 
> > Comments?
> 
> I think "Total pages reclaimed" increasing is not good thing ;)

First, I made a mistake in the patch. With the bug fixed, they're
reduced. See the post later in the thread
http://lkml.org/lkml/2010/1/6/215

> Honestly, I haven't understand why your patch increase reclaimed and
> the exactly meaning of the your tool's rclm field.
> 
> Can you share your mesurement script? May I run the same test?
> 

Unfortunately at the moment it's part of a mini-testgrid setup I run out
of the house. It doesn't lend itself to being stand-alone. I'll break it
out as part of the next release.

> I like this patch, but I don't like increasing reclaim. I'd like to know
> this patch require any vmscan change and/or its change mitigate the issue.
> 

With the bug repaired, reclaims go from 105132 to 45935 with more huge
pages allocated so right now, no special action is required.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

--
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:[~2010-01-21 10:11 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-06 16:26 [RFC-PATCH 0/7] Memory Compaction v1 Mel Gorman
2010-01-06 16:26 ` Mel Gorman
2010-01-06 16:26 ` [PATCH 1/7] Allow CONFIG_MIGRATION to be set without CONFIG_NUMA Mel Gorman
2010-01-06 16:26   ` Mel Gorman
2010-01-07 21:46   ` David Rientjes
2010-01-07 21:46     ` David Rientjes
2010-01-07 22:04     ` Christoph Lameter
2010-01-07 22:04       ` Christoph Lameter
2010-01-19 13:00     ` Mel Gorman
2010-01-19 13:00       ` Mel Gorman
2010-01-06 16:26 ` [PATCH 2/7] Export unusable free space index via /proc/pagetypeinfo Mel Gorman
2010-01-06 16:26   ` Mel Gorman
2010-01-06 17:10   ` Adam Litke
2010-01-06 17:10     ` Adam Litke
2010-01-06 17:29     ` Mel Gorman
2010-01-06 17:29       ` Mel Gorman
2010-01-06 23:21   ` Tim Pepper
2010-01-06 23:21     ` Tim Pepper
2010-01-28 22:27   ` David Rientjes
2010-01-28 22:27     ` David Rientjes
2010-02-05 10:23     ` Mel Gorman
2010-02-05 10:23       ` Mel Gorman
2010-02-05 21:40       ` David Rientjes
2010-02-05 21:40         ` David Rientjes
2010-02-08 12:10         ` Mel Gorman
2010-02-08 12:10           ` Mel Gorman
2010-01-06 16:26 ` [PATCH 3/7] Export fragmentation " Mel Gorman
2010-01-06 16:26   ` Mel Gorman
2010-01-06 16:26 ` [PATCH 4/7] Memory compaction core Mel Gorman
2010-01-06 16:26   ` Mel Gorman
2010-01-06 17:50   ` Mel Gorman
2010-01-06 17:50     ` Mel Gorman
2010-01-06 18:22     ` Mel Gorman
2010-01-06 18:22       ` Mel Gorman
2010-01-06 21:37   ` Andi Kleen
2010-01-06 21:37     ` Andi Kleen
2010-01-06 22:07     ` Mel Gorman
2010-01-06 22:07       ` Mel Gorman
2010-01-06 16:26 ` [PATCH 5/7] Add /proc trigger for memory compaction Mel Gorman
2010-01-06 16:26   ` Mel Gorman
2010-01-07 22:00   ` David Rientjes
2010-01-07 22:00     ` David Rientjes
2010-01-13 23:23     ` David Rientjes
2010-01-13 23:23       ` David Rientjes
2010-01-20  9:48       ` Mel Gorman
2010-01-20  9:48         ` Mel Gorman
2010-01-20  9:48     ` Mel Gorman
2010-01-20  9:48       ` Mel Gorman
2010-01-20 18:12       ` Christoph Lameter
2010-01-20 18:12         ` Christoph Lameter
2010-01-20 20:53         ` Mel Gorman
2010-01-20 20:53           ` Mel Gorman
2010-01-20 20:48       ` David Rientjes
2010-01-20 20:48         ` David Rientjes
2010-01-21 14:09         ` Mel Gorman
2010-01-21 14:09           ` Mel Gorman
2010-01-21 23:34           ` David Rientjes
2010-01-21 23:34             ` David Rientjes
2010-01-06 16:26 ` [PATCH 6/7] Direct compact when a high-order allocation fails Mel Gorman
2010-01-06 16:26   ` Mel Gorman
2010-01-06 16:26 ` [PATCH 7/7] Do not compact within a preferred zone after a compaction failure Mel Gorman
2010-01-06 16:26   ` Mel Gorman
2010-01-13 23:28   ` David Rientjes
2010-01-13 23:28     ` David Rientjes
2010-01-20  9:51     ` Mel Gorman
2010-01-20  9:51       ` Mel Gorman
2010-01-21  3:12 ` [RFC-PATCH 0/7] Memory Compaction v1 KOSAKI Motohiro
2010-01-21  3:12   ` KOSAKI Motohiro
2010-01-21 10:11   ` Mel Gorman [this message]
2010-01-21 10:11     ` Mel Gorman
2010-01-22  0:16     ` KOSAKI Motohiro
2010-01-22  0:16       ` KOSAKI Motohiro

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=20100121101112.GH5154@csn.ul.ie \
    --to=mel@csn.ul.ie \
    --cc=aarcange@redhat.com \
    --cc=agl@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=cl@linux-foundation.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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 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.