linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: 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: [PATCH 4/7] Memory compaction core
Date: Wed, 6 Jan 2010 18:22:43 +0000	[thread overview]
Message-ID: <20100106182243.GC5426@csn.ul.ie> (raw)
In-Reply-To: <20100106175031.GB5426@csn.ul.ie>

On Wed, Jan 06, 2010 at 05:50:32PM +0000, Mel Gorman wrote:
> > +		/* Found a free page, break it into order-0 pages */
> > +		isolated = split_free_page(page);
> > +		total_isolated += isolated;
> > +		for (i = 0; i < isolated; i++) {
> > +			list_add(&page->lru, freelist);
> > +			page++;
> 
> 
> > +			blockpfn += isolated - 1;
> 
> *sigh*
> 
> This increment is wrong. It pushs blockpfn forward too fast and takes fewer
> free pages than it should from that pageblock.
> 

I should point out that the consequence of this is that pages are not
being isolated properly and the free scanner moves too quickly. This
both aborts the compaction early and the end result is not as compact.

With this stupidity repaired, the results become

Starting page count: 0
Requesting at each increment: 50 huge pages
1: 50 pages Success time:0.09 rclm:8192 cblock:59 csuccess:20 alloc: 50/50
2: 100 pages Success time:0.09 rclm:3924 cblock:80 csuccess:28 alloc: 50/50
3: 150 pages Success time:0.08 rclm:4088 cblock:110 csuccess:26 alloc: 50/50
4: 200 pages Success time:0.15 rclm:4749 cblock:148 csuccess:32 alloc: 50/50
5: 250 pages Success time:0.05 rclm:7142 cblock:56 csuccess:17 alloc: 50/50
6: 300 pages Success time:0.08 rclm:6361 cblock:38 csuccess:11 alloc: 50/50
7: 350 pages Success time:0.04 rclm:6220 cblock:40 csuccess:11 alloc: 50/50
8: 400 pages Success time:0.01 rclm:1037 cblock:12 csuccess:11 alloc: 50/50
9: 450 pages Success time:0.01 rclm:203 cblock:13 csuccess:14 alloc: 50/50
10: 500 pages Success time:0.06 rclm:32 cblock:137 csuccess:33 alloc: 50/50
11: 550 pages Success time:0.03 rclm:0 cblock:67 csuccess:16 alloc: 50/50
12: 600 pages Success time:0.01 rclm:0 cblock:11 csuccess:11 alloc: 50/50
13: 650 pages Success time:0.00 rclm:0 cblock:0 csuccess:2 alloc: 50/50
14: 700 pages Success time:0.01 rclm:0 cblock:0 csuccess:5 alloc: 50/50
15: 750 pages Success time:0.00 rclm:0 cblock:0 csuccess:0 alloc: 50/50
16: 800 pages Success time:0.00 rclm:0 cblock:3 csuccess:17 alloc: 50/50
17: 850 pages Success time:0.01 rclm:0 cblock:6 csuccess:3 alloc: 50/50
18: 895 pages Success time:0.30 rclm:70 cblock:62 csuccess:16 alloc: 45/50
19: 900 pages Success time:0.39 rclm:415 cblock:78 csuccess:2 alloc: 5/50
20: 900 pages Failed time:0.09 rclm:53 cblock:48 csuccess:0
21: 902 pages Success time:0.04 rclm:0 cblock:21 csuccess:1 alloc: 2/50
22: 902 pages Failed time:0.04 rclm:0 cblock:21 csuccess:0
23: 902 pages Failed time:0.09 rclm:1017 cblock:47 csuccess:0
24: 903 pages Success time:0.04 rclm:0 cblock:22 csuccess:0 alloc: 1/50
25: 903 pages Failed time:0.58 rclm:464 cblock:67 csuccess:0
26: 911 pages Success time:0.06 rclm:0 cblock:22 csuccess:1 alloc: 8/50
27: 911 pages Failed time:0.04 rclm:0 cblock:21 csuccess:0
28: 917 pages Success time:0.86 rclm:224 cblock:94 csuccess:2 alloc: 6/50
29: 918 pages Success time:0.04 rclm:0 cblock:23 csuccess:1 alloc: 1/50
30: 918 pages Failed time:0.30 rclm:413 cblock:48 csuccess:0
31: 919 pages Success time:0.19 rclm:486 cblock:52 csuccess:0 alloc: 1/50
32: 919 pages Failed time:0.04 rclm:0 cblock:14 csuccess:0
33: 919 pages Failed time:0.23 rclm:425 cblock:52 csuccess:0
34: 919 pages Failed time:0.04 rclm:0 cblock:14 csuccess:0
35: 919 pages Failed time:0.15 rclm:420 cblock:48 csuccess:0
36: 919 pages Failed time:0.04 rclm:0 cblock:14 csuccess:0
Final page count:            919
Total pages reclaimed:       45935
Total blocks compacted:      1548
Total compact pages alloced: 280

So that it works much more as expected. Reclaims are way down, allocation
success rates are still very high.

Credit goes to Eric Munson who pointed the bug out to be on IRC.

-- 
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-06 18:23 UTC|newest]

Thread overview: 36+ 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 ` [PATCH 1/7] Allow CONFIG_MIGRATION to be set without CONFIG_NUMA Mel Gorman
2010-01-07 21:46   ` David Rientjes
2010-01-07 22:04     ` Christoph Lameter
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 17:10   ` Adam Litke
2010-01-06 17:29     ` Mel Gorman
2010-01-06 23:21   ` Tim Pepper
2010-01-28 22:27   ` David Rientjes
2010-02-05 10:23     ` Mel Gorman
2010-02-05 21:40       ` David Rientjes
2010-02-08 12:10         ` Mel Gorman
2010-01-06 16:26 ` [PATCH 3/7] Export fragmentation " Mel Gorman
2010-01-06 16:26 ` [PATCH 4/7] Memory compaction core Mel Gorman
2010-01-06 17:50   ` Mel Gorman
2010-01-06 18:22     ` Mel Gorman [this message]
2010-01-06 21:37   ` Andi Kleen
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-07 22:00   ` 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 18:12       ` Christoph Lameter
2010-01-20 20:53         ` Mel Gorman
2010-01-20 20:48       ` David Rientjes
2010-01-21 14:09         ` Mel Gorman
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 ` [PATCH 7/7] Do not compact within a preferred zone after a compaction failure Mel Gorman
2010-01-13 23:28   ` David Rientjes
2010-01-20  9:51     ` Mel Gorman
2010-01-21  3:12 ` [RFC-PATCH 0/7] Memory Compaction v1 KOSAKI Motohiro
2010-01-21 10:11   ` Mel Gorman
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=20100106182243.GC5426@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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).