All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Jim Schutt <jaschut@sandia.gov>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
	Mel Gorman <mel@csn.ul.ie>,
	kamezawa.hiroyu@jp.fujitsu.com, minchan@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm] mm: have order>0 compaction start off where it left
Date: Thu, 28 Jun 2012 13:25:38 -0400	[thread overview]
Message-ID: <4FEC9392.2090904@redhat.com> (raw)
In-Reply-To: <4FEC9181.9060000@sandia.gov>

On 06/28/2012 01:16 PM, Jim Schutt wrote:
>
> On 06/27/2012 09:37 PM, 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.
>>
>> Reported-by: Jim Schutt<jaschut@sandia.gov>
>> Signed-off-by: Rik van Riel<riel@redhat.com>
>
> Tested-by: Jim Schutt<jaschut@sandia.gov>
>
> Please let me know if you further refine this patch
> and would like me to test it with my workload.

Mel pointed out a serious problem with the way wrapping
cc->free_pfn back to the top of the zone is handled.

I will send you a new patch once I have a fix for that.

> So far I've run a total of ~20 TB of data over fifty minutes
> or so through 12 machines running this patch; no hint of
> trouble, great performance.
>
> Without this patch I would typically start having trouble
> after just a few minutes of this load.

Good to hear that!

Thank you for testing last night's version.

-- 
All rights reversed

--
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: Rik van Riel <riel@redhat.com>
To: Jim Schutt <jaschut@sandia.gov>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
	Mel Gorman <mel@csn.ul.ie>,
	kamezawa.hiroyu@jp.fujitsu.com, minchan@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm] mm: have order>0 compaction start off where it left
Date: Thu, 28 Jun 2012 13:25:38 -0400	[thread overview]
Message-ID: <4FEC9392.2090904@redhat.com> (raw)
In-Reply-To: <4FEC9181.9060000@sandia.gov>

On 06/28/2012 01:16 PM, Jim Schutt wrote:
>
> On 06/27/2012 09:37 PM, 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.
>>
>> Reported-by: Jim Schutt<jaschut@sandia.gov>
>> Signed-off-by: Rik van Riel<riel@redhat.com>
>
> Tested-by: Jim Schutt<jaschut@sandia.gov>
>
> Please let me know if you further refine this patch
> and would like me to test it with my workload.

Mel pointed out a serious problem with the way wrapping
cc->free_pfn back to the top of the zone is handled.

I will send you a new patch once I have a fix for that.

> So far I've run a total of ~20 TB of data over fifty minutes
> or so through 12 machines running this patch; no hint of
> trouble, great performance.
>
> Without this patch I would typically start having trouble
> after just a few minutes of this load.

Good to hear that!

Thank you for testing last night's version.

-- 
All rights reversed

  reply	other threads:[~2012-06-28 17:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-28  3:37 [PATCH -mm] mm: have order>0 compaction start off where it left Rik van Riel
2012-06-28  3:37 ` Rik van Riel
2012-06-28 10:29 ` Mel Gorman
2012-06-28 10:29   ` Mel Gorman
2012-06-28 16:30   ` Rik van Riel
2012-06-28 16:30     ` Rik van Riel
2012-06-29  2:58     ` Kamezawa Hiroyuki
2012-06-29  2:58       ` Kamezawa Hiroyuki
2012-06-28 17:16 ` Jim Schutt
2012-06-28 17:16   ` Jim Schutt
2012-06-28 17:25   ` Rik van Riel [this message]
2012-06-28 17:25     ` Rik van Riel

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=4FEC9392.2090904@redhat.com \
    --to=riel@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=jaschut@sandia.gov \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=minchan@kernel.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.