From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail137.messagelabs.com (mail137.messagelabs.com [216.82.249.19])
	by kanga.kvack.org (Postfix) with SMTP id B2E006B01F0
	for <linux-mm@kvack.org>; Tue, 17 Aug 2010 07:04:41 -0400 (EDT)
Received: from m5.gw.fujitsu.co.jp ([10.0.50.75])
	by fgwmail5.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id o7HB4duS020405
	for <linux-mm@kvack.org> (envelope-from iram.shahzad@jp.fujitsu.com);
	Tue, 17 Aug 2010 20:04:39 +0900
Received: from smail (m5 [127.0.0.1])
	by outgoing.m5.gw.fujitsu.co.jp (Postfix) with ESMTP id 7808545DE4F
	for <linux-mm@kvack.org>; Tue, 17 Aug 2010 20:04:39 +0900 (JST)
Received: from s5.gw.fujitsu.co.jp (s5.gw.fujitsu.co.jp [10.0.50.95])
	by m5.gw.fujitsu.co.jp (Postfix) with ESMTP id 5756645DE4E
	for <linux-mm@kvack.org>; Tue, 17 Aug 2010 20:04:39 +0900 (JST)
Received: from s5.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s5.gw.fujitsu.co.jp (Postfix) with ESMTP id 3FE101DB8040
	for <linux-mm@kvack.org>; Tue, 17 Aug 2010 20:04:39 +0900 (JST)
Received: from ml13.s.css.fujitsu.com (ml13.s.css.fujitsu.com [10.249.87.103])
	by s5.gw.fujitsu.co.jp (Postfix) with ESMTP id F27281DB803C
	for <linux-mm@kvack.org>; Tue, 17 Aug 2010 20:04:38 +0900 (JST)
Message-ID: <325E0A25FE724BA18190186F058FF37E@rainbow>
From: "Iram Shahzad" <iram.shahzad@jp.fujitsu.com>
Subject: compaction: trying to understand the code
Date: Tue, 17 Aug 2010 20:08:54 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-15";
	reply-type=response
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mm@kvack.org
To: Mel Gorman <mel@csn.ul.ie>
Cc: linux-mm@kvack.org
List-ID: <linux-mm.kvack.org>

Hi

I am trying to understand the following code in isolate_migratepages
function. I have a question regarding this.

---
 while (unlikely(too_many_isolated(zone))) {
  congestion_wait(BLK_RW_ASYNC, HZ/10);

  if (fatal_signal_pending(current))
   return 0;
 }

---

I have seen that in some cases this while loop never exits
because too_many_isolated keeps returning true for ever.
And hence the process hangs. Is this intended behaviour?
What is it that is supposed to change the "too_many_isolated" situation?
In other words, what is it that is supposed to increase the "inactive"
or decrease the "isolated" so that isolated > inactive becomes false?

Best regards
Iram


--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51])
	by kanga.kvack.org (Postfix) with ESMTP id 6F3196B01F2
	for <linux-mm@kvack.org>; Tue, 17 Aug 2010 07:10:34 -0400 (EDT)
Date: Tue, 17 Aug 2010 12:10:18 +0100
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100817111018.GQ19797@csn.ul.ie>
References: <325E0A25FE724BA18190186F058FF37E@rainbow>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <325E0A25FE724BA18190186F058FF37E@rainbow>
Sender: owner-linux-mm@kvack.org
To: Iram Shahzad <iram.shahzad@jp.fujitsu.com>
Cc: linux-mm@kvack.org
List-ID: <linux-mm.kvack.org>

On Tue, Aug 17, 2010 at 08:08:54PM +0900, Iram Shahzad wrote:
> Hi
>
> I am trying to understand the following code in isolate_migratepages
> function. I have a question regarding this.
>
> ---
> while (unlikely(too_many_isolated(zone))) {
>  congestion_wait(BLK_RW_ASYNC, HZ/10);
>
>  if (fatal_signal_pending(current))
>   return 0;
> }
>
> ---
>
> I have seen that in some cases this while loop never exits
> because too_many_isolated keeps returning true for ever.
> And hence the process hangs. Is this intended behaviour?

No. Under what circumstances does it get stuck forever. It's similar
logic to what's in page reclaim except there parallel processes such as
kswapd or direct reclaimers would eventually release isolated pages.

> What is it that is supposed to change the "too_many_isolated" situation?

Parallel reclaimers or compaction processes releasing the pages they
have isolated from the LRU.

> In other words, what is it that is supposed to increase the "inactive"
> or decrease the "isolated" so that isolated > inactive becomes false?
>

See places that update the NR_ISOLATED_ANON and NR_ISOLATED_FILE
counters.

-- 
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail191.messagelabs.com (mail191.messagelabs.com [216.82.242.19])
	by kanga.kvack.org (Postfix) with SMTP id E36986B01F2
	for <linux-mm@kvack.org>; Wed, 18 Aug 2010 04:15:04 -0400 (EDT)
Received: from m2.gw.fujitsu.co.jp ([10.0.50.72])
	by fgwmail7.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id o7I8F1L8006473
	for <linux-mm@kvack.org> (envelope-from iram.shahzad@jp.fujitsu.com);
	Wed, 18 Aug 2010 17:15:01 +0900
Received: from smail (m2 [127.0.0.1])
	by outgoing.m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 0AB1945DE51
	for <linux-mm@kvack.org>; Wed, 18 Aug 2010 17:15:01 +0900 (JST)
Received: from s2.gw.fujitsu.co.jp (s2.gw.fujitsu.co.jp [10.0.50.92])
	by m2.gw.fujitsu.co.jp (Postfix) with ESMTP id DE50E45DE4F
	for <linux-mm@kvack.org>; Wed, 18 Aug 2010 17:15:00 +0900 (JST)
Received: from s2.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id C6C641DB8038
	for <linux-mm@kvack.org>; Wed, 18 Aug 2010 17:15:00 +0900 (JST)
Received: from m108.s.css.fujitsu.com (m108.s.css.fujitsu.com [10.249.87.108])
	by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id 2ABEA1DB803B
	for <linux-mm@kvack.org>; Wed, 18 Aug 2010 17:14:57 +0900 (JST)
Message-ID: <4385155269B445AEAF27DC8639A953D7@rainbow>
From: "Iram Shahzad" <iram.shahzad@jp.fujitsu.com>
References: <325E0A25FE724BA18190186F058FF37E@rainbow> <20100817111018.GQ19797@csn.ul.ie>
Subject: Re: compaction: trying to understand the code
Date: Wed, 18 Aug 2010 17:19:21 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-15";
	reply-type=original
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mm@kvack.org
To: Mel Gorman <mel@csn.ul.ie>
Cc: linux-mm@kvack.org
List-ID: <linux-mm.kvack.org>

>> In other words, what is it that is supposed to increase the "inactive"
>> or decrease the "isolated" so that isolated > inactive becomes false?
>>
> 
> See places that update the NR_ISOLATED_ANON and NR_ISOLATED_FILE
> counters.

Many thanks for the advice.
So far as I understand, to come out of the loop, somehow NR_ISOLATED_*
has to be decremented. And the code that decrements it is called here:
mm/migrate.c migrate_pages() -> unmap_and_move()

In compaction.c, migrate_pages() is called only after returning from 
isolate_migratepages().
So if it is looping inside isolate_migratepages() function, migrate_pages()
will not be called and hence there is no chance for NR_ISOLATED_*
to be decremented. Am I wrong?

Best regards
Iram


--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243])
	by kanga.kvack.org (Postfix) with SMTP id 1A7D16B01F1
	for <linux-mm@kvack.org>; Wed, 18 Aug 2010 11:41:45 -0400 (EDT)
Date: Wed, 18 Aug 2010 23:41:30 +0800
From: Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100818154130.GC9431@localhost>
References: <325E0A25FE724BA18190186F058FF37E@rainbow>
 <20100817111018.GQ19797@csn.ul.ie>
 <4385155269B445AEAF27DC8639A953D7@rainbow>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4385155269B445AEAF27DC8639A953D7@rainbow>
Sender: owner-linux-mm@kvack.org
To: Iram Shahzad <iram.shahzad@jp.fujitsu.com>
Cc: Mel Gorman <mel@csn.ul.ie>, linux-mm@kvack.org, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Wed, Aug 18, 2010 at 05:19:21PM +0900, Iram Shahzad wrote:
> >>In other words, what is it that is supposed to increase the "inactive"
> >>or decrease the "isolated" so that isolated > inactive becomes false?
> >>
> >
> >See places that update the NR_ISOLATED_ANON and NR_ISOLATED_FILE
> >counters.
> 
> Many thanks for the advice.
> So far as I understand, to come out of the loop, somehow NR_ISOLATED_*
> has to be decremented. And the code that decrements it is called here:
> mm/migrate.c migrate_pages() -> unmap_and_move()
> 
> In compaction.c, migrate_pages() is called only after returning from
> isolate_migratepages().
> So if it is looping inside isolate_migratepages() function, migrate_pages()
> will not be called and hence there is no chance for NR_ISOLATED_*
> to be decremented. Am I wrong?

The loop should be waiting for the _other_ processes (doing direct
reclaims) to proceed.  When there are _lots of_ ongoing page
allocations/reclaims, it makes sense to wait for them to calm down a bit?

Thanks,
Fengguang

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3])
	by kanga.kvack.org (Postfix) with SMTP id B5A406B01F1
	for <linux-mm@kvack.org>; Thu, 19 Aug 2010 03:05:19 -0400 (EDT)
Received: from m4.gw.fujitsu.co.jp ([10.0.50.74])
	by fgwmail6.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id o7J75H6V010451
	for <linux-mm@kvack.org> (envelope-from iram.shahzad@jp.fujitsu.com);
	Thu, 19 Aug 2010 16:05:17 +0900
Received: from smail (m4 [127.0.0.1])
	by outgoing.m4.gw.fujitsu.co.jp (Postfix) with ESMTP id F21BC45DE4D
	for <linux-mm@kvack.org>; Thu, 19 Aug 2010 16:05:16 +0900 (JST)
Received: from s4.gw.fujitsu.co.jp (s4.gw.fujitsu.co.jp [10.0.50.94])
	by m4.gw.fujitsu.co.jp (Postfix) with ESMTP id C2A3E45DE6E
	for <linux-mm@kvack.org>; Thu, 19 Aug 2010 16:05:16 +0900 (JST)
Received: from s4.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 96DC5EF8001
	for <linux-mm@kvack.org>; Thu, 19 Aug 2010 16:05:16 +0900 (JST)
Received: from ml14.s.css.fujitsu.com (ml14.s.css.fujitsu.com [10.249.87.104])
	by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 512851DB803A
	for <linux-mm@kvack.org>; Thu, 19 Aug 2010 16:05:16 +0900 (JST)
Message-ID: <565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
From: "Iram Shahzad" <iram.shahzad@jp.fujitsu.com>
References: <325E0A25FE724BA18190186F058FF37E@rainbow> <20100817111018.GQ19797@csn.ul.ie> <4385155269B445AEAF27DC8639A953D7@rainbow> <20100818154130.GC9431@localhost>
Subject: Re: compaction: trying to understand the code
Date: Thu, 19 Aug 2010 16:09:38 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="ISO-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mm@kvack.org
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Mel Gorman <mel@csn.ul.ie>, linux-mm@kvack.org, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

> The loop should be waiting for the _other_ processes (doing direct
> reclaims) to proceed.  When there are _lots of_ ongoing page
> allocations/reclaims, it makes sense to wait for them to calm down a bit?

I have noticed that if I run other process, it helps the loop to exit.
So is this (ie hanging until other process helps) intended behaviour?

Also, the other process does help the loop to exit, but again it enters
the loop and the compaction is never finished. That is, the process
looks like hanging. Is this intended behaviour?
What will improve this situation?

Thanks
Iram


--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35])
	by kanga.kvack.org (Postfix) with SMTP id 23E1C6B01F1
	for <linux-mm@kvack.org>; Thu, 19 Aug 2010 03:45:08 -0400 (EDT)
Date: Thu, 19 Aug 2010 15:45:04 +0800
From: Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100819074504.GA17393@localhost>
References: <325E0A25FE724BA18190186F058FF37E@rainbow>
 <20100817111018.GQ19797@csn.ul.ie>
 <4385155269B445AEAF27DC8639A953D7@rainbow>
 <20100818154130.GC9431@localhost>
 <565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
Sender: owner-linux-mm@kvack.org
To: Iram Shahzad <iram.shahzad@jp.fujitsu.com>
Cc: Mel Gorman <mel@csn.ul.ie>, "linux-mm@kvack.org" <linux-mm@kvack.org>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Thu, Aug 19, 2010 at 03:09:38PM +0800, Iram Shahzad wrote:
> > The loop should be waiting for the _other_ processes (doing direct
> > reclaims) to proceed.  When there are _lots of_ ongoing page
> > allocations/reclaims, it makes sense to wait for them to calm down a bit?
> 
> I have noticed that if I run other process, it helps the loop to exit.
> So is this (ie hanging until other process helps) intended behaviour?
>
> Also, the other process does help the loop to exit, but again it enters
> the loop and the compaction is never finished. That is, the process
> looks like hanging. Is this intended behaviour?
> What will improve this situation?
 
What's your /proc/vmstat?  Does your system have thousands of
processes allocating memory concurrently? I'd like to make sure the
too_many_isolated() test is working as expected..

Thanks,
Fengguang

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51])
	by kanga.kvack.org (Postfix) with ESMTP id 8AA066B01F2
	for <linux-mm@kvack.org>; Thu, 19 Aug 2010 03:46:19 -0400 (EDT)
Date: Thu, 19 Aug 2010 08:46:02 +0100
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100819074602.GW19797@csn.ul.ie>
References: <325E0A25FE724BA18190186F058FF37E@rainbow> <20100817111018.GQ19797@csn.ul.ie> <4385155269B445AEAF27DC8639A953D7@rainbow> <20100818154130.GC9431@localhost> <565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
Sender: owner-linux-mm@kvack.org
To: Iram Shahzad <iram.shahzad@jp.fujitsu.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>, linux-mm@kvack.org, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Thu, Aug 19, 2010 at 04:09:38PM +0900, Iram Shahzad wrote:
>> The loop should be waiting for the _other_ processes (doing direct
>> reclaims) to proceed.  When there are _lots of_ ongoing page
>> allocations/reclaims, it makes sense to wait for them to calm down a bit?
>
> I have noticed that if I run other process, it helps the loop to exit.
> So is this (ie hanging until other process helps) intended behaviour?
>

No, it's not but I'm not immediately seeing how it would occur either.
too_many_isolated() should only be true when there are multiple
processes running that are isolating pages be it due to reclaim or
compaction. These should be finishing their work after some time so
while a process may stall in too_many_isolated(), it should not stay
there forever.

The loop around isolate_migratepages() puts back LRU pages it failed to
migrate so it's not the case that the compacting process is isolating a
large number of pages and then calling too_many_isolated() against itself.

> Also, the other process does help the loop to exit, but again it enters
> the loop and the compaction is never finished. That is, the process
> looks like hanging. Is this intended behaviour?

Infinite loops are never intended behaviour.

> What will improve this situation?

What is your test scenario? Who or what has these pages isolated that is
allowing too_many_isolated() to be true?

I'm not seeing how processes could isolate a large number of pages and
hold onto them for a long time but knowing the test scenario might help.

-- 
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51])
	by kanga.kvack.org (Postfix) with SMTP id 8D6876B01F5
	for <linux-mm@kvack.org>; Thu, 19 Aug 2010 04:08:35 -0400 (EDT)
Date: Thu, 19 Aug 2010 16:08:31 +0800
From: Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100819080830.GA17899@localhost>
References: <325E0A25FE724BA18190186F058FF37E@rainbow>
 <20100817111018.GQ19797@csn.ul.ie>
 <4385155269B445AEAF27DC8639A953D7@rainbow>
 <20100818154130.GC9431@localhost>
 <565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
 <20100819074602.GW19797@csn.ul.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100819074602.GW19797@csn.ul.ie>
Sender: owner-linux-mm@kvack.org
To: Mel Gorman <mel@csn.ul.ie>
Cc: Iram Shahzad <iram.shahzad@jp.fujitsu.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Thu, Aug 19, 2010 at 03:46:02PM +0800, Mel Gorman wrote:
> On Thu, Aug 19, 2010 at 04:09:38PM +0900, Iram Shahzad wrote:
> >> The loop should be waiting for the _other_ processes (doing direct
> >> reclaims) to proceed.  When there are _lots of_ ongoing page
> >> allocations/reclaims, it makes sense to wait for them to calm down a bit?
> >
> > I have noticed that if I run other process, it helps the loop to exit.
> > So is this (ie hanging until other process helps) intended behaviour?
> >
> 
> No, it's not but I'm not immediately seeing how it would occur either.
> too_many_isolated() should only be true when there are multiple
> processes running that are isolating pages be it due to reclaim or
> compaction. These should be finishing their work after some time so
> while a process may stall in too_many_isolated(), it should not stay
> there forever.
> 
> The loop around isolate_migratepages() puts back LRU pages it failed to
> migrate so it's not the case that the compacting process is isolating a
> large number of pages and then calling too_many_isolated() against itself.

It seems the compaction process isolates 128MB pages at a time? That
sounds risky, too_many_isolated() can easily be true, which will stall
direct reclaim processes. I'm not seeing how exactly it makes
compaction itself stall infinitely though.

> > Also, the other process does help the loop to exit, but again it enters
> > the loop and the compaction is never finished. That is, the process
> > looks like hanging. Is this intended behaviour?
> 
> Infinite loops are never intended behaviour.

Yup.

Thanks,
Fengguang

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3])
	by kanga.kvack.org (Postfix) with ESMTP id 18FFC6B01F2
	for <linux-mm@kvack.org>; Thu, 19 Aug 2010 04:16:11 -0400 (EDT)
Date: Thu, 19 Aug 2010 09:15:54 +0100
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100819081554.GY19797@csn.ul.ie>
References: <325E0A25FE724BA18190186F058FF37E@rainbow> <20100817111018.GQ19797@csn.ul.ie> <4385155269B445AEAF27DC8639A953D7@rainbow> <20100818154130.GC9431@localhost> <565A4EE71DAC4B1A820B2748F56ABF73@rainbow> <20100819074602.GW19797@csn.ul.ie> <20100819080830.GA17899@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <20100819080830.GA17899@localhost>
Sender: owner-linux-mm@kvack.org
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Iram Shahzad <iram.shahzad@jp.fujitsu.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Thu, Aug 19, 2010 at 04:08:31PM +0800, Wu Fengguang wrote:
> On Thu, Aug 19, 2010 at 03:46:02PM +0800, Mel Gorman wrote:
> > On Thu, Aug 19, 2010 at 04:09:38PM +0900, Iram Shahzad wrote:
> > >> The loop should be waiting for the _other_ processes (doing direct
> > >> reclaims) to proceed.  When there are _lots of_ ongoing page
> > >> allocations/reclaims, it makes sense to wait for them to calm down a bit?
> > >
> > > I have noticed that if I run other process, it helps the loop to exit.
> > > So is this (ie hanging until other process helps) intended behaviour?
> > >
> > 
> > No, it's not but I'm not immediately seeing how it would occur either.
> > too_many_isolated() should only be true when there are multiple
> > processes running that are isolating pages be it due to reclaim or
> > compaction. These should be finishing their work after some time so
> > while a process may stall in too_many_isolated(), it should not stay
> > there forever.
> > 
> > The loop around isolate_migratepages() puts back LRU pages it failed to
> > migrate so it's not the case that the compacting process is isolating a
> > large number of pages and then calling too_many_isolated() against itself.
> 
> It seems the compaction process isolates 128MB pages at a time?

It should be one pageblock at a time for source migration and one pageblock
for target pages. Look at the values for low_pfn and end_pfn here;

static unsigned long isolate_migratepages(struct zone *zone,
                                        struct compact_control *cc)
{
        unsigned long low_pfn, end_pfn;
        struct list_head *migratelist = &cc->migratepages;

        /* Do not scan outside zone boundaries */
        low_pfn = max(cc->migrate_pfn, zone->zone_start_pfn);

        /* Only scan within a pageblock boundary */
        end_pfn = ALIGN(low_pfn + pageblock_nr_pages, pageblock_nr_pages);

....

and the loop around that looks like

        while ((ret = compact_finished(zone, cc)) == COMPACT_CONTINUE) {
                unsigned long nr_migrate, nr_remaining;

                if (!isolate_migratepages(zone, cc))
                        continue;

                nr_migrate = cc->nr_migratepages;
                migrate_pages(&cc->migratepages, compaction_alloc,
                                                (unsigned long)cc, 0);
                update_nr_listpages(cc);
                nr_remaining = cc->nr_migratepages;

                count_vm_event(COMPACTBLOCKS);
                count_vm_events(COMPACTPAGES, nr_migrate - nr_remaining);
                if (nr_remaining)
                        count_vm_events(COMPACTPAGEFAILED, nr_remaining);

                /* Release LRU pages not migrated */
                if (!list_empty(&cc->migratepages)) {
                        putback_lru_pages(&cc->migratepages);
                        cc->nr_migratepages = 0;
                }

        }

Where is it isolating 128MB?

> That
> sounds risky, too_many_isolated() can easily be true, which will stall
> direct reclaim processes. I'm not seeing how exactly it makes
> compaction itself stall infinitely though.
> 
> > > Also, the other process does help the loop to exit, but again it enters
> > > the loop and the compaction is never finished. That is, the process
> > > looks like hanging. Is this intended behaviour?
> > 
> > Infinite loops are never intended behaviour.
> 
> Yup.
> 

-- 
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail137.messagelabs.com (mail137.messagelabs.com [216.82.249.19])
	by kanga.kvack.org (Postfix) with SMTP id A81FB6B01F5
	for <linux-mm@kvack.org>; Thu, 19 Aug 2010 04:29:56 -0400 (EDT)
Date: Thu, 19 Aug 2010 16:29:36 +0800
From: Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100819082936.GA18801@localhost>
References: <325E0A25FE724BA18190186F058FF37E@rainbow>
 <20100817111018.GQ19797@csn.ul.ie>
 <4385155269B445AEAF27DC8639A953D7@rainbow>
 <20100818154130.GC9431@localhost>
 <565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
 <20100819074602.GW19797@csn.ul.ie>
 <20100819080830.GA17899@localhost>
 <20100819081554.GY19797@csn.ul.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100819081554.GY19797@csn.ul.ie>
Sender: owner-linux-mm@kvack.org
To: Mel Gorman <mel@csn.ul.ie>
Cc: Iram Shahzad <iram.shahzad@jp.fujitsu.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Thu, Aug 19, 2010 at 04:15:54PM +0800, Mel Gorman wrote:
> On Thu, Aug 19, 2010 at 04:08:31PM +0800, Wu Fengguang wrote:
> > On Thu, Aug 19, 2010 at 03:46:02PM +0800, Mel Gorman wrote:
> > > On Thu, Aug 19, 2010 at 04:09:38PM +0900, Iram Shahzad wrote:
> > > >> The loop should be waiting for the _other_ processes (doing direct
> > > >> reclaims) to proceed.  When there are _lots of_ ongoing page
> > > >> allocations/reclaims, it makes sense to wait for them to calm down a bit?
> > > >
> > > > I have noticed that if I run other process, it helps the loop to exit.
> > > > So is this (ie hanging until other process helps) intended behaviour?
> > > >
> > > 
> > > No, it's not but I'm not immediately seeing how it would occur either.
> > > too_many_isolated() should only be true when there are multiple
> > > processes running that are isolating pages be it due to reclaim or
> > > compaction. These should be finishing their work after some time so
> > > while a process may stall in too_many_isolated(), it should not stay
> > > there forever.
> > > 
> > > The loop around isolate_migratepages() puts back LRU pages it failed to
> > > migrate so it's not the case that the compacting process is isolating a
> > > large number of pages and then calling too_many_isolated() against itself.
> > 
> > It seems the compaction process isolates 128MB pages at a time?
> 
> It should be one pageblock at a time for source migration and one pageblock
> for target pages. Look at the values for low_pfn and end_pfn here;

Ah sorry! I confused it with section size..

Thanks,
Fengguang

> static unsigned long isolate_migratepages(struct zone *zone,
>                                         struct compact_control *cc)
> {
>         unsigned long low_pfn, end_pfn;
>         struct list_head *migratelist = &cc->migratepages;
> 
>         /* Do not scan outside zone boundaries */
>         low_pfn = max(cc->migrate_pfn, zone->zone_start_pfn);
> 
>         /* Only scan within a pageblock boundary */
>         end_pfn = ALIGN(low_pfn + pageblock_nr_pages, pageblock_nr_pages);
> 
> ....
> 
> and the loop around that looks like
> 
>         while ((ret = compact_finished(zone, cc)) == COMPACT_CONTINUE) {
>                 unsigned long nr_migrate, nr_remaining;
> 
>                 if (!isolate_migratepages(zone, cc))
>                         continue;
> 
>                 nr_migrate = cc->nr_migratepages;
>                 migrate_pages(&cc->migratepages, compaction_alloc,
>                                                 (unsigned long)cc, 0);
>                 update_nr_listpages(cc);
>                 nr_remaining = cc->nr_migratepages;
> 
>                 count_vm_event(COMPACTBLOCKS);
>                 count_vm_events(COMPACTPAGES, nr_migrate - nr_remaining);
>                 if (nr_remaining)
>                         count_vm_events(COMPACTPAGEFAILED, nr_remaining);
> 
>                 /* Release LRU pages not migrated */
>                 if (!list_empty(&cc->migratepages)) {
>                         putback_lru_pages(&cc->migratepages);
>                         cc->nr_migratepages = 0;
>                 }
> 
>         }
> 
> Where is it isolating 128MB?
> 
> > That
> > sounds risky, too_many_isolated() can easily be true, which will stall
> > direct reclaim processes. I'm not seeing how exactly it makes
> > compaction itself stall infinitely though.
> > 
> > > > Also, the other process does help the loop to exit, but again it enters
> > > > the loop and the compaction is never finished. That is, the process
> > > > looks like hanging. Is this intended behaviour?
> > > 
> > > Infinite loops are never intended behaviour.
> > 
> > Yup.
> > 
> 
> -- 
> 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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243])
	by kanga.kvack.org (Postfix) with SMTP id D7CF66B02B5
	for <linux-mm@kvack.org>; Thu, 19 Aug 2010 12:00:12 -0400 (EDT)
Received: by pzk33 with SMTP id 33so905397pzk.14
        for <linux-mm@kvack.org>; Thu, 19 Aug 2010 09:00:13 -0700 (PDT)
Date: Fri, 20 Aug 2010 01:00:07 +0900
From: Minchan Kim <minchan.kim@gmail.com>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100819160006.GG6805@barrios-desktop>
References: <325E0A25FE724BA18190186F058FF37E@rainbow>
 <20100817111018.GQ19797@csn.ul.ie>
 <4385155269B445AEAF27DC8639A953D7@rainbow>
 <20100818154130.GC9431@localhost>
 <565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
Sender: owner-linux-mm@kvack.org
To: Iram Shahzad <iram.shahzad@jp.fujitsu.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>, Mel Gorman <mel@csn.ul.ie>, linux-mm@kvack.org, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Thu, Aug 19, 2010 at 04:09:38PM +0900, Iram Shahzad wrote:
> >The loop should be waiting for the _other_ processes (doing direct
> >reclaims) to proceed.  When there are _lots of_ ongoing page
> >allocations/reclaims, it makes sense to wait for them to calm down a bit?
> 
> I have noticed that if I run other process, it helps the loop to exit.
> So is this (ie hanging until other process helps) intended behaviour?
> 
> Also, the other process does help the loop to exit, but again it enters
> the loop and the compaction is never finished. That is, the process
> looks like hanging. Is this intended behaviour?
> What will improve this situation?
> 
I don't know why too many pages are isolated.
Could you apply below patch for debugging and report it?

diff --git a/mm/compaction.c b/mm/compaction.c
index 94cce51..17f339f 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -215,6 +215,7 @@ static void acct_isolated(struct zone *zone, struct compact_control *cc)
 static bool too_many_isolated(struct zone *zone)
 {
 
+       int overflow = 0;
        unsigned long inactive, isolated;
 
        inactive = zone_page_state(zone, NR_INACTIVE_FILE) +
@@ -222,7 +223,13 @@ static bool too_many_isolated(struct zone *zone)
        isolated = zone_page_state(zone, NR_ISOLATED_FILE) +
                                        zone_page_state(zone, NR_ISOLATED_ANON);
 
-       return isolated > inactive;
+       if (isolated > inactive)
+               overflow = 1;
+
+       if (overflow)
+               show_mem();     
+
+       return overflow;
 }


> Thanks
> Iram
> 
> 
> --
> 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>

-- 
Kind regards,
Minchan Kim

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail191.messagelabs.com (mail191.messagelabs.com [216.82.242.19])
	by kanga.kvack.org (Postfix) with SMTP id 820796B02BD
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 01:26:46 -0400 (EDT)
Received: from m4.gw.fujitsu.co.jp ([10.0.50.74])
	by fgwmail6.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id o7K5QgDC007082
	for <linux-mm@kvack.org> (envelope-from iram.shahzad@jp.fujitsu.com);
	Fri, 20 Aug 2010 14:26:42 +0900
Received: from smail (m4 [127.0.0.1])
	by outgoing.m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 880C645DE4D
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 14:26:42 +0900 (JST)
Received: from s4.gw.fujitsu.co.jp (s4.gw.fujitsu.co.jp [10.0.50.94])
	by m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 6560F45DE60
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 14:26:42 +0900 (JST)
Received: from s4.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id E0FAFE38002
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 14:26:41 +0900 (JST)
Received: from m107.s.css.fujitsu.com (m107.s.css.fujitsu.com [10.249.87.107])
	by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 756091DB8037
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 14:26:41 +0900 (JST)
Message-ID: <AA3F2D89535A431DB91FE3032EDCB9EA@rainbow>
From: "Iram Shahzad" <iram.shahzad@jp.fujitsu.com>
References: <325E0A25FE724BA18190186F058FF37E@rainbow> <20100817111018.GQ19797@csn.ul.ie> <4385155269B445AEAF27DC8639A953D7@rainbow> <20100818154130.GC9431@localhost> <565A4EE71DAC4B1A820B2748F56ABF73@rainbow> <20100819160006.GG6805@barrios-desktop>
Subject: Re: compaction: trying to understand the code
Date: Fri, 20 Aug 2010 14:31:03 +0900
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_00CA_01CB4074.51799E60"
Sender: owner-linux-mm@kvack.org
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>, Mel Gorman <mel@csn.ul.ie>, linux-mm@kvack.org, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

This is a multi-part message in MIME format.

------=_NextPart_000_00CA_01CB4074.51799E60
Content-Type: text/plain;
	format=flowed;
	charset="ISO-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit

> Could you apply below patch for debugging and report it?

The Mem-info gets printed forever. So I have picked the first 2 of them
and then another 2 after some time. These 4 Mem-infos are shown in
the attached log.

Thanks
Iram

------=_NextPart_000_00CA_01CB4074.51799E60
Content-Type: text/plain;
	format=flowed;
	name="too_many_isolated_log.txt";
	reply-type=original
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="too_many_isolated_log.txt"

Mem-info:
Normal per-cpu:
CPU    0: hi:  186, btch:  31 usd: 184
active_anon:40345 inactive_anon:0 isolated_anon:8549
 active_file:2713 inactive_file:10418 isolated_file:1871
 unevictable:0 dirty:0 writeback:0 unstable:0
 free:53713 slab_reclaimable:533 slab_unreclaimable:1076
 mapped:9461 shmem:2349 pagetables:1574 bounce:0
Normal free:214852kB min:2884kB low:3604kB high:4324kB =
active_anon:161380kB inactive_anon:0kB active_file:10852kB =
inactive_file:41672kB unevictable:0kB isolated(anon):34196kB =
isolated(file):7484kB present:520192kB mlocked:0kB dirty:0kB =
writeback:0kB mapped:37844kB shmem:9396kB slab_reclaimable:2132kB =
slab_unreclaimable:4304kB kernel_stack:1880kB pagetables:6296kB =
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 =
all_unreclaimable? no
lowmem_reserve[]: 0 0 0
Normal: 31*4kB 29*8kB 20*16kB 23*32kB 21*64kB 19*128kB 19*256kB 20*512kB =
20*1024kB 3*2048kB 41*4096kB =3D 214852kB
15491 total pagecache pages
131072 pages of RAM
54242 free pages
18897 reserved pages
1609 slab pages
84316 pages shared
0 pages swap cached
Mem-info:
Normal per-cpu:
CPU    0: hi:  186, btch:  31 usd: 184
active_anon:40345 inactive_anon:0 isolated_anon:8549
 active_file:2713 inactive_file:10418 isolated_file:1871
 unevictable:0 dirty:0 writeback:0 unstable:0
 free:53713 slab_reclaimable:533 slab_unreclaimable:1076
 mapped:9461 shmem:2349 pagetables:1574 bounce:0
Normal free:214852kB min:2884kB low:3604kB high:4324kB =
active_anon:161380kB inactive_anon:0kB active_file:10852kB =
inactive_file:41672kB unevictable:0kB isolated(anon):34196kB =
isolated(file):7484kB present:520192kB mlocked:0kB dirty:0kB =
writeback:0kB mapped:37844kB shmem:9396kB slab_reclaimable:2132kB =
slab_unreclaimable:4304kB kernel_stack:1880kB pagetables:6296kB =
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 =
all_unreclaimable? no
lowmem_reserve[]: 0 0 0
Normal: 26*4kB 27*8kB 19*16kB 22*32kB 20*64kB 19*128kB 19*256kB 20*512kB =
20*1024kB 3*2048kB 41*4096kB =3D 214704kB
15491 total pagecache pages
131072 pages of RAM
54258 free pages
18897 reserved pages
1609 slab pages
84296 pages shared
0 pages swap cached


[snip]


Mem-info:
Normal per-cpu:
CPU    0: hi:  186, btch:  31 usd: 100
active_anon:40429 inactive_anon:0 isolated_anon:8581
 active_file:2719 inactive_file:10423 isolated_file:1871
 unevictable:0 dirty:0 writeback:0 unstable:0
 free:53777 slab_reclaimable:534 slab_unreclaimable:1070
 mapped:9461 shmem:2349 pagetables:1574 bounce:0
Normal free:215108kB min:2884kB low:3604kB high:4324kB =
active_anon:161716kB inactive_anon:0kB active_file:10876kB =
inactive_file:41692kB unevictable:0kB isolated(anon):34324kB =
isolated(file):7484kB present:520192kB mlocked:0kB dirty:0kB =
writeback:0kB mapped:37844kB shmem:9396kB slab_reclaimable:2136kB =
slab_unreclaimable:4280kB kernel_stack:1872kB pagetables:6296kB =
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 =
all_unreclaimable? no
lowmem_reserve[]: 0 0 0
Normal: 31*4kB 29*8kB 20*16kB 21*32kB 22*64kB 19*128kB 20*256kB 20*512kB =
20*1024kB 3*2048kB 41*4096kB =3D 215108kB
15491 total pagecache pages
131072 pages of RAM
54221 free pages
18897 reserved pages
1604 slab pages
84289 pages shared
0 pages swap cached
Mem-info:
Normal per-cpu:
CPU    0: hi:  186, btch:  31 usd: 100
active_anon:40429 inactive_anon:0 isolated_anon:8581
 active_file:2719 inactive_file:10423 isolated_file:1871
 unevictable:0 dirty:0 writeback:0 unstable:0
 free:53777 slab_reclaimable:534 slab_unreclaimable:1070
 mapped:9461 shmem:2349 pagetables:1574 bounce:0
Normal free:215108kB min:2884kB low:3604kB high:4324kB =
active_anon:161716kB inactive_anon:0kB active_file:10876kB =
inactive_file:41692kB unevictable:0kB isolated(anon):34324kB =
isolated(file):7484kB present:520192kB mlocked:0kB dirty:0kB =
writeback:0kB mapped:37844kB shmem:9396kB slab_reclaimable:2136kB =
slab_unreclaimable:4280kB kernel_stack:1872kB pagetables:6296kB =
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 =
all_unreclaimable? no
lowmem_reserve[]: 0 0 0
Normal: 31*4kB 29*8kB 20*16kB 21*32kB 22*64kB 19*128kB 20*256kB 20*512kB =
20*1024kB 3*2048kB 41*4096kB =3D 215108kB
15491 total pagecache pages
131072 pages of RAM
54222 free pages
18897 reserved pages
1603 slab pages
84289 pages shared
0 pages swap cached

------=_NextPart_000_00CA_01CB4074.51799E60--


--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51])
	by kanga.kvack.org (Postfix) with SMTP id 89B586B02BF
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 01:34:56 -0400 (EDT)
Date: Fri, 20 Aug 2010 13:34:47 +0800
From: Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100820053447.GA13406@localhost>
References: <325E0A25FE724BA18190186F058FF37E@rainbow>
 <20100817111018.GQ19797@csn.ul.ie>
 <4385155269B445AEAF27DC8639A953D7@rainbow>
 <20100818154130.GC9431@localhost>
 <565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
 <20100819160006.GG6805@barrios-desktop>
 <AA3F2D89535A431DB91FE3032EDCB9EA@rainbow>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AA3F2D89535A431DB91FE3032EDCB9EA@rainbow>
Sender: owner-linux-mm@kvack.org
To: Iram Shahzad <iram.shahzad@jp.fujitsu.com>
Cc: Minchan Kim <minchan.kim@gmail.com>, Mel Gorman <mel@csn.ul.ie>, "linux-mm@kvack.org" <linux-mm@kvack.org>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

You do run lots of tasks: kernel_stack=1880kB.

And you have lots of free memory, page reclaim has never run, so
inactive_anon=0. This is where compaction is different from vmscan.
In vmscan, inactive_anon is reasonably large, and will only be
compared directly with isolated_anon.

Thanks,
Fengguang

On Fri, Aug 20, 2010 at 01:31:03PM +0800, Iram Shahzad wrote:
> > Could you apply below patch for debugging and report it?
> 
> The Mem-info gets printed forever. So I have picked the first 2 of them
> and then another 2 after some time. These 4 Mem-infos are shown in
> the attached log.
> 
> Thanks
> Iram

> Mem-info:
> Normal per-cpu:
> CPU    0: hi:  186, btch:  31 usd: 184
> active_anon:40345 inactive_anon:0 isolated_anon:8549
>  active_file:2713 inactive_file:10418 isolated_file:1871
>  unevictable:0 dirty:0 writeback:0 unstable:0
>  free:53713 slab_reclaimable:533 slab_unreclaimable:1076
>  mapped:9461 shmem:2349 pagetables:1574 bounce:0
> Normal free:214852kB min:2884kB low:3604kB high:4324kB active_anon:161380kB inactive_anon:0kB active_file:10852kB inactive_file:41672kB unevictable:0kB isolated(anon):34196kB isolated(file):7484kB present:520192kB mlocked:0kB dirty:0kB writeback:0kB mapped:37844kB shmem:9396kB slab_reclaimable:2132kB slab_unreclaimable:4304kB kernel_stack:1880kB pagetables:6296kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 0 0
> Normal: 31*4kB 29*8kB 20*16kB 23*32kB 21*64kB 19*128kB 19*256kB 20*512kB 20*1024kB 3*2048kB 41*4096kB = 214852kB
> 15491 total pagecache pages
> 131072 pages of RAM
> 54242 free pages
> 18897 reserved pages
> 1609 slab pages
> 84316 pages shared
> 0 pages swap cached
> Mem-info:
> Normal per-cpu:
> CPU    0: hi:  186, btch:  31 usd: 184
> active_anon:40345 inactive_anon:0 isolated_anon:8549
>  active_file:2713 inactive_file:10418 isolated_file:1871
>  unevictable:0 dirty:0 writeback:0 unstable:0
>  free:53713 slab_reclaimable:533 slab_unreclaimable:1076
>  mapped:9461 shmem:2349 pagetables:1574 bounce:0
> Normal free:214852kB min:2884kB low:3604kB high:4324kB active_anon:161380kB inactive_anon:0kB active_file:10852kB inactive_file:41672kB unevictable:0kB isolated(anon):34196kB isolated(file):7484kB present:520192kB mlocked:0kB dirty:0kB writeback:0kB mapped:37844kB shmem:9396kB slab_reclaimable:2132kB slab_unreclaimable:4304kB kernel_stack:1880kB pagetables:6296kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 0 0
> Normal: 26*4kB 27*8kB 19*16kB 22*32kB 20*64kB 19*128kB 19*256kB 20*512kB 20*1024kB 3*2048kB 41*4096kB = 214704kB
> 15491 total pagecache pages
> 131072 pages of RAM
> 54258 free pages
> 18897 reserved pages
> 1609 slab pages
> 84296 pages shared
> 0 pages swap cached
> 
> 
> [snip]
> 
> 
> Mem-info:
> Normal per-cpu:
> CPU    0: hi:  186, btch:  31 usd: 100
> active_anon:40429 inactive_anon:0 isolated_anon:8581
>  active_file:2719 inactive_file:10423 isolated_file:1871
>  unevictable:0 dirty:0 writeback:0 unstable:0
>  free:53777 slab_reclaimable:534 slab_unreclaimable:1070
>  mapped:9461 shmem:2349 pagetables:1574 bounce:0
> Normal free:215108kB min:2884kB low:3604kB high:4324kB active_anon:161716kB inactive_anon:0kB active_file:10876kB inactive_file:41692kB unevictable:0kB isolated(anon):34324kB isolated(file):7484kB present:520192kB mlocked:0kB dirty:0kB writeback:0kB mapped:37844kB shmem:9396kB slab_reclaimable:2136kB slab_unreclaimable:4280kB kernel_stack:1872kB pagetables:6296kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 0 0
> Normal: 31*4kB 29*8kB 20*16kB 21*32kB 22*64kB 19*128kB 20*256kB 20*512kB 20*1024kB 3*2048kB 41*4096kB = 215108kB
> 15491 total pagecache pages
> 131072 pages of RAM
> 54221 free pages
> 18897 reserved pages
> 1604 slab pages
> 84289 pages shared
> 0 pages swap cached
> Mem-info:
> Normal per-cpu:
> CPU    0: hi:  186, btch:  31 usd: 100
> active_anon:40429 inactive_anon:0 isolated_anon:8581
>  active_file:2719 inactive_file:10423 isolated_file:1871
>  unevictable:0 dirty:0 writeback:0 unstable:0
>  free:53777 slab_reclaimable:534 slab_unreclaimable:1070
>  mapped:9461 shmem:2349 pagetables:1574 bounce:0
> Normal free:215108kB min:2884kB low:3604kB high:4324kB active_anon:161716kB inactive_anon:0kB active_file:10876kB inactive_file:41692kB unevictable:0kB isolated(anon):34324kB isolated(file):7484kB present:520192kB mlocked:0kB dirty:0kB writeback:0kB mapped:37844kB shmem:9396kB slab_reclaimable:2136kB slab_unreclaimable:4280kB kernel_stack:1872kB pagetables:6296kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 0 0
> Normal: 31*4kB 29*8kB 20*16kB 21*32kB 22*64kB 19*128kB 20*256kB 20*512kB 20*1024kB 3*2048kB 41*4096kB = 215108kB
> 15491 total pagecache pages
> 131072 pages of RAM
> 54222 free pages
> 18897 reserved pages
> 1603 slab pages
> 84289 pages shared
> 0 pages swap cached

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51])
	by kanga.kvack.org (Postfix) with SMTP id A95876B02C4
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 01:41:33 -0400 (EDT)
Received: from m3.gw.fujitsu.co.jp ([10.0.50.73])
	by fgwmail6.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id o7K5fVM9013741
	for <linux-mm@kvack.org> (envelope-from iram.shahzad@jp.fujitsu.com);
	Fri, 20 Aug 2010 14:41:31 +0900
Received: from smail (m3 [127.0.0.1])
	by outgoing.m3.gw.fujitsu.co.jp (Postfix) with ESMTP id 299DE45DE51
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 14:41:31 +0900 (JST)
Received: from s3.gw.fujitsu.co.jp (s3.gw.fujitsu.co.jp [10.0.50.93])
	by m3.gw.fujitsu.co.jp (Postfix) with ESMTP id A8EFD45DE53
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 14:41:30 +0900 (JST)
Received: from s3.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 7DEBD1DB8037
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 14:41:30 +0900 (JST)
Received: from m108.s.css.fujitsu.com (m108.s.css.fujitsu.com [10.249.87.108])
	by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 0554FE18001
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 14:41:30 +0900 (JST)
Message-ID: <5EF4FA9117384B1A80228C96926B4125@rainbow>
From: "Iram Shahzad" <iram.shahzad@jp.fujitsu.com>
References: <325E0A25FE724BA18190186F058FF37E@rainbow> <20100817111018.GQ19797@csn.ul.ie> <4385155269B445AEAF27DC8639A953D7@rainbow> <20100818154130.GC9431@localhost> <565A4EE71DAC4B1A820B2748F56ABF73@rainbow> <20100819074602.GW19797@csn.ul.ie>
Subject: Re: compaction: trying to understand the code
Date: Fri, 20 Aug 2010 14:45:56 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-15";
	reply-type=original
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mm@kvack.org
To: Mel Gorman <mel@csn.ul.ie>
Cc: Wu Fengguang <fengguang.wu@intel.com>, linux-mm@kvack.org, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

> What is your test scenario? Who or what has these pages isolated that is
> allowing too_many_isolated() to be true?

I have a test app that attempts to create fragmentation. Then I run
echo 1 > /proc/sys/vm/compact_memory
That is all.
The test app mallocs 2MB 100 times, memsets them.
Then it frees the even numbered 2MB blocks.
That is, 2MB*50 remains malloced and 2MB*50 gets freed.

Thanks
Iram


--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227])
	by kanga.kvack.org (Postfix) with SMTP id 0E4B36B02C7
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 01:50:14 -0400 (EDT)
Date: Fri, 20 Aug 2010 13:50:06 +0800
From: Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100820055006.GA13916@localhost>
References: <325E0A25FE724BA18190186F058FF37E@rainbow>
 <20100817111018.GQ19797@csn.ul.ie>
 <4385155269B445AEAF27DC8639A953D7@rainbow>
 <20100818154130.GC9431@localhost>
 <565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
 <20100819074602.GW19797@csn.ul.ie>
 <5EF4FA9117384B1A80228C96926B4125@rainbow>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5EF4FA9117384B1A80228C96926B4125@rainbow>
Sender: owner-linux-mm@kvack.org
To: Iram Shahzad <iram.shahzad@jp.fujitsu.com>
Cc: Mel Gorman <mel@csn.ul.ie>, "linux-mm@kvack.org" <linux-mm@kvack.org>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>, Ying Han <yinghan@google.com>
List-ID: <linux-mm.kvack.org>

On Fri, Aug 20, 2010 at 01:45:56PM +0800, Iram Shahzad wrote:
> > What is your test scenario? Who or what has these pages isolated that is
> > allowing too_many_isolated() to be true?
> 
> I have a test app that attempts to create fragmentation. Then I run
> echo 1 > /proc/sys/vm/compact_memory
> That is all.

That's all? Is you system idle otherwise? (for example, fresh booted
and not running many processes)

> The test app mallocs 2MB 100 times, memsets them.
> Then it frees the even numbered 2MB blocks.
> That is, 2MB*50 remains malloced and 2MB*50 gets freed.
 
We are interested in the test app, can you share it? :)

Thanks,
Fengguang

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail191.messagelabs.com (mail191.messagelabs.com [216.82.242.19])
	by kanga.kvack.org (Postfix) with SMTP id 053E76B02CE
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 02:09:12 -0400 (EDT)
Received: from m5.gw.fujitsu.co.jp ([10.0.50.75])
	by fgwmail6.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id o7K69Aiu025703
	for <linux-mm@kvack.org> (envelope-from iram.shahzad@jp.fujitsu.com);
	Fri, 20 Aug 2010 15:09:10 +0900
Received: from smail (m5 [127.0.0.1])
	by outgoing.m5.gw.fujitsu.co.jp (Postfix) with ESMTP id 007D445DE56
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 15:09:10 +0900 (JST)
Received: from s5.gw.fujitsu.co.jp (s5.gw.fujitsu.co.jp [10.0.50.95])
	by m5.gw.fujitsu.co.jp (Postfix) with ESMTP id AD8EB45DE4F
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 15:09:09 +0900 (JST)
Received: from s5.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s5.gw.fujitsu.co.jp (Postfix) with ESMTP id 61A1AE18002
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 15:09:09 +0900 (JST)
Received: from ml13.s.css.fujitsu.com (ml13.s.css.fujitsu.com [10.249.87.103])
	by s5.gw.fujitsu.co.jp (Postfix) with ESMTP id 09DF81DB8038
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 15:09:09 +0900 (JST)
Message-ID: <F185F1F1FF284307ABD7BA74DB4747D1@rainbow>
From: "Iram Shahzad" <iram.shahzad@jp.fujitsu.com>
References: <325E0A25FE724BA18190186F058FF37E@rainbow> <20100817111018.GQ19797@csn.ul.ie> <4385155269B445AEAF27DC8639A953D7@rainbow> <20100818154130.GC9431@localhost> <565A4EE71DAC4B1A820B2748F56ABF73@rainbow> <20100819074602.GW19797@csn.ul.ie> <5EF4FA9117384B1A80228C96926B4125@rainbow> <20100820055006.GA13916@localhost>
Subject: Re: compaction: trying to understand the code
Date: Fri, 20 Aug 2010 15:13:33 +0900
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_00E8_01CB407A.41303FE0"
Sender: owner-linux-mm@kvack.org
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Mel Gorman <mel@csn.ul.ie>, linux-mm@kvack.org, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>, Ying Han <yinghan@google.com>
List-ID: <linux-mm.kvack.org>

This is a multi-part message in MIME format.

------=_NextPart_000_00E8_01CB407A.41303FE0
Content-Type: text/plain;
	format=flowed;
	charset="ISO-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit

> That's all? Is you system idle otherwise? (for example, fresh booted
> and not running many processes)

Sorry, I didn't mean that. There are other processes running.
I just meant my test doesn't do anything else.

> We are interested in the test app, can you share it? :)

Attached.

Thanks
Iram

------=_NextPart_000_00E8_01CB407A.41303FE0
Content-Type: application/octet-stream;
	name="mfragprog.c"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="mfragprog.c"

#include <stdlib.h>
#include <stdio.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <asm/types.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdint.h>
#include <errno.h>
#include <string.h>

#define TRYNUMMAX (1024*50)
static void *p[TRYNUMMAX] =3D {(void *)1, };
static size_t size;
static int trynum;

static void mfrag(void)
{
	int i;

	fprintf(stderr, "size, trynum: %d %d\n", size, trynum);

	for (i=3D0; i<trynum; i++) {
			p[i] =3D NULL;
	}

	for (i=3D0; i<trynum; i++) {
		p[i] =3D malloc(size);
		if (p[i]) {
			fprintf(stderr, "(%s:%s:%d) Success %d %d %p\n", __FILE__, =
__FUNCTION__, __LINE__, size, i, p[i]);
			memset(p[i], 'a', size);
		}
		else {
			fprintf(stderr, "(%s:%s:%d) Fail %d %d\n", __FILE__, __FUNCTION__, =
__LINE__, size, i);
			break;
		}
	}

	fprintf(stderr, "%d allocs done\n", i);

	for (i=3D0; i<trynum; i+=3D2) {
		if (p[i]) {
			free(p[i]);
			p[i] =3D NULL;
		}
	}

	fprintf(stderr, "frag done\n");
}

int main (int argc, char **argv)
{
	if (argc !=3D 3) {
		fprintf(stderr, "usage: %s <size> <trynum>\n", argv[0]);
		exit(1);
	}

	size =3D atoi(argv[1]);
	trynum =3D atoi(argv[2]);
	if (trynum > TRYNUMMAX) {
		trynum =3D TRYNUMMAX;
	}
=09
	mfrag();
=09
	while (1) {
		fprintf(stdout, "(%s:%s:%d)\n", __FILE__, __FUNCTION__, __LINE__);
		sleep(3);
	}
}

------=_NextPart_000_00E8_01CB407A.41303FE0--


--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail191.messagelabs.com (mail191.messagelabs.com [216.82.242.19])
	by kanga.kvack.org (Postfix) with ESMTP id 144576B02F0
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 05:36:18 -0400 (EDT)
Date: Fri, 20 Aug 2010 10:35:59 +0100
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100820093558.GG19797@csn.ul.ie>
References: <325E0A25FE724BA18190186F058FF37E@rainbow> <20100817111018.GQ19797@csn.ul.ie> <4385155269B445AEAF27DC8639A953D7@rainbow> <20100818154130.GC9431@localhost> <565A4EE71DAC4B1A820B2748F56ABF73@rainbow> <20100819160006.GG6805@barrios-desktop> <AA3F2D89535A431DB91FE3032EDCB9EA@rainbow> <20100820053447.GA13406@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <20100820053447.GA13406@localhost>
Sender: owner-linux-mm@kvack.org
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Iram Shahzad <iram.shahzad@jp.fujitsu.com>, Minchan Kim <minchan.kim@gmail.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Fri, Aug 20, 2010 at 01:34:47PM +0800, Wu Fengguang wrote:
> You do run lots of tasks: kernel_stack=1880kB.
> 
> And you have lots of free memory, page reclaim has never run, so
> inactive_anon=0. This is where compaction is different from vmscan.
> In vmscan, inactive_anon is reasonably large, and will only be
> compared directly with isolated_anon.
> 

True, the key observation here was that compaction is being run via the
proc trigger. Normally it would be run as part of the direct reclaim
path when kswapd would already be awake. too_many_isolated() needs to be
different for compaction to take the whole system into account. What
would be the best alternative? Here is one possibility. A reasonable
alternative would be that when inactive < active that isolated can't be
more than num_online_cpus() * 2 (i.e. one compactor per online cpu).

diff --git a/mm/compaction.c b/mm/compaction.c
index 94cce51..1e000b7 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -215,14 +215,16 @@ static void acct_isolated(struct zone *zone, struct compact_control *cc)
 static bool too_many_isolated(struct zone *zone)
 {
 
-	unsigned long inactive, isolated;
+	unsigned long active, inactive, isolated;
 
+	active = zone_page_state(zone, NR_ACTIVE_FILE) +
+					zone_page_state(zone, NR_INACTIVE_ANON);
 	inactive = zone_page_state(zone, NR_INACTIVE_FILE) +
 					zone_page_state(zone, NR_INACTIVE_ANON);
 	isolated = zone_page_state(zone, NR_ISOLATED_FILE) +
 					zone_page_state(zone, NR_ISOLATED_ANON);
 
-	return isolated > inactive;
+	return (inactive > active) ? isolated > inactive : false;
 }
 
 /*

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227])
	by kanga.kvack.org (Postfix) with SMTP id 0B7826B031D
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 06:24:01 -0400 (EDT)
Date: Fri, 20 Aug 2010 18:23:55 +0800
From: Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100820102355.GE8440@localhost>
References: <325E0A25FE724BA18190186F058FF37E@rainbow>
 <20100817111018.GQ19797@csn.ul.ie>
 <4385155269B445AEAF27DC8639A953D7@rainbow>
 <20100818154130.GC9431@localhost>
 <565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
 <20100819160006.GG6805@barrios-desktop>
 <AA3F2D89535A431DB91FE3032EDCB9EA@rainbow>
 <20100820053447.GA13406@localhost>
 <20100820093558.GG19797@csn.ul.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100820093558.GG19797@csn.ul.ie>
Sender: owner-linux-mm@kvack.org
To: Mel Gorman <mel@csn.ul.ie>
Cc: Iram Shahzad <iram.shahzad@jp.fujitsu.com>, Minchan Kim <minchan.kim@gmail.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Fri, Aug 20, 2010 at 05:35:59PM +0800, Mel Gorman wrote:
> On Fri, Aug 20, 2010 at 01:34:47PM +0800, Wu Fengguang wrote:
> > You do run lots of tasks: kernel_stack=1880kB.
> > 
> > And you have lots of free memory, page reclaim has never run, so
> > inactive_anon=0. This is where compaction is different from vmscan.
> > In vmscan, inactive_anon is reasonably large, and will only be
> > compared directly with isolated_anon.
> > 
> 
> True, the key observation here was that compaction is being run via the
> proc trigger. Normally it would be run as part of the direct reclaim
> path when kswapd would already be awake. too_many_isolated() needs to be
> different for compaction to take the whole system into account. What
> would be the best alternative? Here is one possibility. A reasonable
> alternative would be that when inactive < active that isolated can't be
> more than num_online_cpus() * 2 (i.e. one compactor per online cpu).
>
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 94cce51..1e000b7 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -215,14 +215,16 @@ static void acct_isolated(struct zone *zone, struct compact_control *cc)
>  static bool too_many_isolated(struct zone *zone)
>  {
>  
> -	unsigned long inactive, isolated;
> +	unsigned long active, inactive, isolated;
>  
> +	active = zone_page_state(zone, NR_ACTIVE_FILE) +
> +					zone_page_state(zone, NR_INACTIVE_ANON);

s/NR_INACTIVE_ANON/NR_ACTIVE_ANON/

>  	inactive = zone_page_state(zone, NR_INACTIVE_FILE) +
>  					zone_page_state(zone, NR_INACTIVE_ANON);
>  	isolated = zone_page_state(zone, NR_ISOLATED_FILE) +
>  					zone_page_state(zone, NR_ISOLATED_ANON);
>  
> -	return isolated > inactive;
> +	return (inactive > active) ? isolated > inactive : false;

Note that for anon LRU, inactive_ratio may be large numbers.
(inactive > active) is not easy, and not stable even when inactive_ratio=1.

Thanks,
Fengguang

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail143.messagelabs.com (mail143.messagelabs.com [216.82.254.35])
	by kanga.kvack.org (Postfix) with SMTP id 42F5D6B0320
	for <linux-mm@kvack.org>; Fri, 20 Aug 2010 06:30:18 -0400 (EDT)
Received: by iwn33 with SMTP id 33so925371iwn.14
        for <linux-mm@kvack.org>; Fri, 20 Aug 2010 03:30:18 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <20100820093558.GG19797@csn.ul.ie>
References: <325E0A25FE724BA18190186F058FF37E@rainbow>
	<20100817111018.GQ19797@csn.ul.ie>
	<4385155269B445AEAF27DC8639A953D7@rainbow>
	<20100818154130.GC9431@localhost>
	<565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
	<20100819160006.GG6805@barrios-desktop>
	<AA3F2D89535A431DB91FE3032EDCB9EA@rainbow>
	<20100820053447.GA13406@localhost>
	<20100820093558.GG19797@csn.ul.ie>
Date: Fri, 20 Aug 2010 19:22:16 +0900
Message-ID: <AANLkTimVmoomDjGMCfKvNrS+v-mMnfeq6JDZzx7fjZi+@mail.gmail.com>
Subject: Re: compaction: trying to understand the code
From: Minchan Kim <minchan.kim@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: owner-linux-mm@kvack.org
To: Mel Gorman <mel@csn.ul.ie>
Cc: Wu Fengguang <fengguang.wu@intel.com>, Iram Shahzad <iram.shahzad@jp.fujitsu.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Fri, Aug 20, 2010 at 6:35 PM, Mel Gorman <mel@csn.ul.ie> wrote:
> On Fri, Aug 20, 2010 at 01:34:47PM +0800, Wu Fengguang wrote:
>> You do run lots of tasks: kernel_stack=3D1880kB.
>>
>> And you have lots of free memory, page reclaim has never run, so
>> inactive_anon=3D0. This is where compaction is different from vmscan.
>> In vmscan, inactive_anon is reasonably large, and will only be
>> compared directly with isolated_anon.
>>
>
> True, the key observation here was that compaction is being run via the
> proc trigger. Normally it would be run as part of the direct reclaim
> path when kswapd would already be awake. too_many_isolated() needs to be
> different for compaction to take the whole system into account. What
> would be the best alternative? Here is one possibility. A reasonable
> alternative would be that when inactive < active that isolated can't be
> more than num_online_cpus() * 2 (i.e. one compactor per online cpu).
>
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 94cce51..1e000b7 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -215,14 +215,16 @@ static void acct_isolated(struct zone *zone, struct=
 compact_control *cc)
> =A0static bool too_many_isolated(struct zone *zone)
> =A0{
>
> - =A0 =A0 =A0 unsigned long inactive, isolated;
> + =A0 =A0 =A0 unsigned long active, inactive, isolated;
>
> + =A0 =A0 =A0 active =3D zone_page_state(zone, NR_ACTIVE_FILE) +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 zone_page_state(zone, NR_INACTIVE_ANON);
> =A0 =A0 =A0 =A0inactive =3D zone_page_state(zone, NR_INACTIVE_FILE) +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0zone_page_state(zone, NR_INACTIVE_ANON);
> =A0 =A0 =A0 =A0isolated =3D zone_page_state(zone, NR_ISOLATED_FILE) +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0zone_page_state(zone, NR_ISOLATED_ANON);
>
> - =A0 =A0 =A0 return isolated > inactive;
> + =A0 =A0 =A0 return (inactive > active) ? isolated > inactive : false;
> =A0}
>
> =A0/*
>

1. active : 1000 inactive : 1000
2. parallel reclaiming -> active : 1000 inactive : 500 isolated : 500
3. too_many_isolated return false.

But in this  case, there are already many isolated pages. So it should
return true.

How about this?
too_many_isolated()
{
      return (isolated > nr_zones * nr_nodes * nr_online_cpu *
SWAP_CLUSTER_MAX);
}
--=20
Kind regards,
Minchan Kim

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51])
	by kanga.kvack.org (Postfix) with SMTP id B838C600044
	for <linux-mm@kvack.org>; Sun, 22 Aug 2010 11:31:30 -0400 (EDT)
Received: by pvc30 with SMTP id 30so2215648pvc.14
        for <linux-mm@kvack.org>; Sun, 22 Aug 2010 08:31:29 -0700 (PDT)
Date: Mon, 23 Aug 2010 00:31:21 +0900
From: Minchan Kim <minchan.kim@gmail.com>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100822153121.GA29389@barrios-desktop>
References: <325E0A25FE724BA18190186F058FF37E@rainbow>
 <20100817111018.GQ19797@csn.ul.ie>
 <4385155269B445AEAF27DC8639A953D7@rainbow>
 <20100818154130.GC9431@localhost>
 <565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
 <20100819160006.GG6805@barrios-desktop>
 <AA3F2D89535A431DB91FE3032EDCB9EA@rainbow>
 <20100820053447.GA13406@localhost>
 <20100820093558.GG19797@csn.ul.ie>
 <AANLkTimVmoomDjGMCfKvNrS+v-mMnfeq6JDZzx7fjZi+@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <AANLkTimVmoomDjGMCfKvNrS+v-mMnfeq6JDZzx7fjZi+@mail.gmail.com>
Sender: owner-linux-mm@kvack.org
To: Mel Gorman <mel@csn.ul.ie>, Andrew Morton <akpm@linux-foundation.org>
Cc: Wu Fengguang <fengguang.wu@intel.com>, Iram Shahzad <iram.shahzad@jp.fujitsu.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Fri, Aug 20, 2010 at 07:22:16PM +0900, Minchan Kim wrote:
> On Fri, Aug 20, 2010 at 6:35 PM, Mel Gorman <mel@csn.ul.ie> wrote:
> > On Fri, Aug 20, 2010 at 01:34:47PM +0800, Wu Fengguang wrote:
> >> You do run lots of tasks: kernel_stack=1880kB.
> >>
> >> And you have lots of free memory, page reclaim has never run, so
> >> inactive_anon=0. This is where compaction is different from vmscan.
> >> In vmscan, inactive_anon is reasonably large, and will only be
> >> compared directly with isolated_anon.
> >>
> >
> > True, the key observation here was that compaction is being run via the
> > proc trigger. Normally it would be run as part of the direct reclaim
> > path when kswapd would already be awake. too_many_isolated() needs to be
> > different for compaction to take the whole system into account. What
> > would be the best alternative? Here is one possibility. A reasonable
> > alternative would be that when inactive < active that isolated can't be
> > more than num_online_cpus() * 2 (i.e. one compactor per online cpu).
> >
> > diff --git a/mm/compaction.c b/mm/compaction.c
> > index 94cce51..1e000b7 100644
> > --- a/mm/compaction.c
> > +++ b/mm/compaction.c
> > @@ -215,14 +215,16 @@ static void acct_isolated(struct zone *zone, struct compact_control *cc)
> >  static bool too_many_isolated(struct zone *zone)
> >  {
> >
> > -       unsigned long inactive, isolated;
> > +       unsigned long active, inactive, isolated;
> >
> > +       active = zone_page_state(zone, NR_ACTIVE_FILE) +
> > +                                       zone_page_state(zone, NR_INACTIVE_ANON);
> >        inactive = zone_page_state(zone, NR_INACTIVE_FILE) +
> >                                        zone_page_state(zone, NR_INACTIVE_ANON);
> >        isolated = zone_page_state(zone, NR_ISOLATED_FILE) +
> >                                        zone_page_state(zone, NR_ISOLATED_ANON);
> >
> > -       return isolated > inactive;
> > +       return (inactive > active) ? isolated > inactive : false;
> >  }
> >
> >  /*
> >
> 
> 1. active : 1000 inactive : 1000
> 2. parallel reclaiming -> active : 1000 inactive : 500 isolated : 500
> 3. too_many_isolated return false.
> 
> But in this  case, there are already many isolated pages. So it should
> return true.
> 
> How about this?
> too_many_isolated()
> {
>       return (isolated > nr_zones * nr_nodes * nr_online_cpu *
> SWAP_CLUSTER_MAX);
> }

Above utterly not good. 
How about this?

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail143.messagelabs.com (mail143.messagelabs.com [216.82.254.35])
	by kanga.kvack.org (Postfix) with SMTP id 254466007D6
	for <linux-mm@kvack.org>; Sun, 22 Aug 2010 19:23:29 -0400 (EDT)
Date: Mon, 23 Aug 2010 07:23:16 +0800
From: Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100822232316.GA339@localhost>
References: <20100817111018.GQ19797@csn.ul.ie>
 <4385155269B445AEAF27DC8639A953D7@rainbow>
 <20100818154130.GC9431@localhost>
 <565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
 <20100819160006.GG6805@barrios-desktop>
 <AA3F2D89535A431DB91FE3032EDCB9EA@rainbow>
 <20100820053447.GA13406@localhost>
 <20100820093558.GG19797@csn.ul.ie>
 <AANLkTimVmoomDjGMCfKvNrS+v-mMnfeq6JDZzx7fjZi+@mail.gmail.com>
 <20100822153121.GA29389@barrios-desktop>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100822153121.GA29389@barrios-desktop>
Sender: owner-linux-mm@kvack.org
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Mel Gorman <mel@csn.ul.ie>, Andrew Morton <akpm@linux-foundation.org>, Iram Shahzad <iram.shahzad@jp.fujitsu.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

> From: Minchan Kim <minchan.kim@gmail.com>
> Date: Mon, 23 Aug 2010 00:20:44 +0900
> Subject: [PATCH] compaction: handle active and inactive fairly in too_many_isolated
> 
> Iram reported compaction's too_many_isolated loops forever.
> (http://www.spinics.net/lists/linux-mm/msg08123.html)
> 
> The meminfo of situation happened was inactive anon is zero.
> That's because the system has no memory pressure until then.
> While all anon pages was in active lru, compaction could select
> active lru as well as inactive lru. That's different things
> with vmscan's isolated. So we has been two too_many_isolated.
> 
> While compaction can isolated pages in both active and inactive,
> current implementation of too_many_isolated only considers inactive.
> It made Iram's problem.
> 
> This patch handles active and inactie with fair.
> That's because we can't expect where from and how many compaction would
> isolated pages.
> 
> This patch changes (nr_isolated > nr_inactive) with
> nr_isolated > (nr_active + nr_inactive) / 2.

The change looks good, thanks. However I'm not sure if it's enough.

I wonder where the >40MB isolated pages come about.  inactive_anon
remains 0 and free remains high over a long time, so it seems there
are no concurrent direct reclaims at all. Are the pages isolated by
the compaction process itself?

Thanks,
Fengguang

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51])
	by kanga.kvack.org (Postfix) with SMTP id 66A0E6B038A
	for <linux-mm@kvack.org>; Sun, 22 Aug 2010 21:58:11 -0400 (EDT)
Received: by iwn33 with SMTP id 33so3810232iwn.14
        for <linux-mm@kvack.org>; Sun, 22 Aug 2010 18:58:09 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <20100822232316.GA339@localhost>
References: <20100817111018.GQ19797@csn.ul.ie>
	<4385155269B445AEAF27DC8639A953D7@rainbow>
	<20100818154130.GC9431@localhost>
	<565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
	<20100819160006.GG6805@barrios-desktop>
	<AA3F2D89535A431DB91FE3032EDCB9EA@rainbow>
	<20100820053447.GA13406@localhost>
	<20100820093558.GG19797@csn.ul.ie>
	<AANLkTimVmoomDjGMCfKvNrS+v-mMnfeq6JDZzx7fjZi+@mail.gmail.com>
	<20100822153121.GA29389@barrios-desktop>
	<20100822232316.GA339@localhost>
Date: Mon, 23 Aug 2010 10:58:09 +0900
Message-ID: <AANLkTim8c5C+vH1HUx-GsScirmnVoJXenLST1qQgk2bp@mail.gmail.com>
Subject: Re: compaction: trying to understand the code
From: Minchan Kim <minchan.kim@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: owner-linux-mm@kvack.org
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Mel Gorman <mel@csn.ul.ie>, Andrew Morton <akpm@linux-foundation.org>, Iram Shahzad <iram.shahzad@jp.fujitsu.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Mon, Aug 23, 2010 at 8:23 AM, Wu Fengguang <fengguang.wu@intel.com> wrot=
e:
>> From: Minchan Kim <minchan.kim@gmail.com>
>> Date: Mon, 23 Aug 2010 00:20:44 +0900
>> Subject: [PATCH] compaction: handle active and inactive fairly in too_ma=
ny_isolated
>>
>> Iram reported compaction's too_many_isolated loops forever.
>> (http://www.spinics.net/lists/linux-mm/msg08123.html)
>>
>> The meminfo of situation happened was inactive anon is zero.
>> That's because the system has no memory pressure until then.
>> While all anon pages was in active lru, compaction could select
>> active lru as well as inactive lru. That's different things
>> with vmscan's isolated. So we has been two too_many_isolated.
>>
>> While compaction can isolated pages in both active and inactive,
>> current implementation of too_many_isolated only considers inactive.
>> It made Iram's problem.
>>
>> This patch handles active and inactie with fair.
>> That's because we can't expect where from and how many compaction would
>> isolated pages.
>>
>> This patch changes (nr_isolated > nr_inactive) with
>> nr_isolated > (nr_active + nr_inactive) / 2.
>
> The change looks good, thanks. However I'm not sure if it's enough.

Thanks.

>
> I wonder where the >40MB isolated pages come about. =A0inactive_anon
> remains 0 and free remains high over a long time, so it seems there
> are no concurrent direct reclaims at all. Are the pages isolated by
> the compaction process itself?

Agree. I wonder too.

Now compaction isolates page per 32 until reaching pageblock_nr_pages,
So I can't understand how 40MB isolated pages come out.

Iram. How do you execute test_app?

1) synchronous test
1.1 start test_app
1.2 wait test_app job done (ie, wait memory is fragment)
1.3 echo 1 > /proc/sys/vm/compact_memory

2) asynchronous test
2.1 start test_app
2.2 not wait test_app job done
2.3 echo 1 > /proc/sys/vm/compact_memory(Maybe your test app and
compaction were executed parallel)

Which one is your scenario?


>
> Thanks,
> Fengguang
>



--=20
Kind regards,
Minchan Kim

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35])
	by kanga.kvack.org (Postfix) with SMTP id 23CDF6B038C
	for <linux-mm@kvack.org>; Sun, 22 Aug 2010 22:59:47 -0400 (EDT)
Received: from m1.gw.fujitsu.co.jp ([10.0.50.71])
	by fgwmail7.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id o7N2xeWQ029347
	for <linux-mm@kvack.org> (envelope-from iram.shahzad@jp.fujitsu.com);
	Mon, 23 Aug 2010 11:59:40 +0900
Received: from smail (m1 [127.0.0.1])
	by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 8F2F545DE4F
	for <linux-mm@kvack.org>; Mon, 23 Aug 2010 11:59:40 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91])
	by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 7327245DE3E
	for <linux-mm@kvack.org>; Mon, 23 Aug 2010 11:59:40 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 5A20E1DB8050
	for <linux-mm@kvack.org>; Mon, 23 Aug 2010 11:59:40 +0900 (JST)
Received: from m108.s.css.fujitsu.com (m108.s.css.fujitsu.com [10.249.87.108])
	by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 14EE21DB804C
	for <linux-mm@kvack.org>; Mon, 23 Aug 2010 11:59:40 +0900 (JST)
Message-ID: <C06122FE6B6044BD94C8A632B205D909@rainbow>
From: "Iram Shahzad" <iram.shahzad@jp.fujitsu.com>
References: <20100817111018.GQ19797@csn.ul.ie><4385155269B445AEAF27DC8639A953D7@rainbow><20100818154130.GC9431@localhost><565A4EE71DAC4B1A820B2748F56ABF73@rainbow><20100819160006.GG6805@barrios-desktop><AA3F2D89535A431DB91FE3032EDCB9EA@rainbow><20100820053447.GA13406@localhost><20100820093558.GG19797@csn.ul.ie><AANLkTimVmoomDjGMCfKvNrS+v-mMnfeq6JDZzx7fjZi+@mail.gmail.com><20100822153121.GA29389@barrios-desktop><20100822232316.GA339@localhost> <AANLkTim8c5C+vH1HUx-GsScirmnVoJXenLST1qQgk2bp@mail.gmail.com>
Subject: Re: compaction: trying to understand the code
Date: Mon, 23 Aug 2010 12:03:55 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="ISO-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mm@kvack.org
To: Minchan Kim <minchan.kim@gmail.com>, Wu Fengguang <fengguang.wu@intel.com>
Cc: Mel Gorman <mel@csn.ul.ie>, Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

> Iram. How do you execute test_app?
>
> 1) synchronous test
> 1.1 start test_app
> 1.2 wait test_app job done (ie, wait memory is fragment)
> 1.3 echo 1 > /proc/sys/vm/compact_memory
>
> 2) asynchronous test
> 2.1 start test_app
> 2.2 not wait test_app job done
> 2.3 echo 1 > /proc/sys/vm/compact_memory(Maybe your test app and
> compaction were executed parallel)

It's synchronous.
First I confirm that the test app has completed its fragmentation work
by looking at the printf output. Then only I run echo 1 > 
/proc/sys/vm/compact_memory.

After completing fragmentation work, my test app sleeps in a useless while 
loop
which I think is not important.

Thanks
Iram


--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51])
	by kanga.kvack.org (Postfix) with ESMTP id BA6AD6007DC
	for <linux-mm@kvack.org>; Mon, 23 Aug 2010 03:16:27 -0400 (EDT)
Date: Mon, 23 Aug 2010 08:16:11 +0100
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100823071610.GL19797@csn.ul.ie>
References: <20100817111018.GQ19797@csn.ul.ie> <4385155269B445AEAF27DC8639A953D7@rainbow> <20100818154130.GC9431@localhost> <565A4EE71DAC4B1A820B2748F56ABF73@rainbow> <20100819160006.GG6805@barrios-desktop> <AA3F2D89535A431DB91FE3032EDCB9EA@rainbow> <20100820053447.GA13406@localhost> <20100820093558.GG19797@csn.ul.ie> <AANLkTimVmoomDjGMCfKvNrS+v-mMnfeq6JDZzx7fjZi+@mail.gmail.com> <20100822153121.GA29389@barrios-desktop>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <20100822153121.GA29389@barrios-desktop>
Sender: owner-linux-mm@kvack.org
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, Wu Fengguang <fengguang.wu@intel.com>, Iram Shahzad <iram.shahzad@jp.fujitsu.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Mon, Aug 23, 2010 at 12:31:21AM +0900, Minchan Kim wrote:
> <SNIP>
> 
> From 560e8898295c663f02aede07b3d55880eba16c69 Mon Sep 17 00:00:00 2001
> From: Minchan Kim <minchan.kim@gmail.com>
> Date: Mon, 23 Aug 2010 00:20:44 +0900
> Subject: [PATCH] compaction: handle active and inactive fairly in too_many_isolated
> 
> Iram reported compaction's too_many_isolated loops forever.
> (http://www.spinics.net/lists/linux-mm/msg08123.html)
> 
> The meminfo of situation happened was inactive anon is zero.
> That's because the system has no memory pressure until then.
> While all anon pages was in active lru, compaction could select
> active lru as well as inactive lru. That's different things
> with vmscan's isolated. So we has been two too_many_isolated.
> 
> While compaction can isolated pages in both active and inactive,
> current implementation of too_many_isolated only considers inactive.
> It made Iram's problem.
> 
> This patch handles active and inactie with fair.
> That's because we can't expect where from and how many compaction would
> isolated pages.
> 
> This patch changes (nr_isolated > nr_inactive) with
> nr_isolated > (nr_active + nr_inactive) / 2.
> 
> Cc: Mel Gorman <mel@csn.ul.ie>
> Cc: Wu Fengguang <fengguang.wu@intel.com>
> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>

Seems reasonable to me.

Acked-by: Mel Gorman <mel@csn.ul.ie>

Want to repost this as a standalone patch?

> ---
>  mm/compaction.c |    9 +++++----
>  1 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 94cce51..0864839 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -214,15 +214,16 @@ static void acct_isolated(struct zone *zone, struct compact_control *cc)
>  /* Similar to reclaim, but different enough that they don't share logic */
>  static bool too_many_isolated(struct zone *zone)
>  {
> -
> -       unsigned long inactive, isolated;
> +       unsigned long active, inactive, isolated;
>  
>         inactive = zone_page_state(zone, NR_INACTIVE_FILE) +
>                                         zone_page_state(zone, NR_INACTIVE_ANON);
> +       active = zone_page_state(zone, NR_ACTIVE_FILE) +
> +                                       zone_page_state(zone, NR_ACTIVE_ANON);
>         isolated = zone_page_state(zone, NR_ISOLATED_FILE) +
>                                         zone_page_state(zone, NR_ISOLATED_ANON);
> -
> -       return isolated > inactive;
> +
> +       return isolated > (inactive + active) / 2;
>  }
> 

-- 
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail191.messagelabs.com (mail191.messagelabs.com [216.82.242.19])
	by kanga.kvack.org (Postfix) with ESMTP id 79FEB6007DC
	for <linux-mm@kvack.org>; Mon, 23 Aug 2010 03:18:19 -0400 (EDT)
Date: Mon, 23 Aug 2010 08:18:04 +0100
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100823071804.GM19797@csn.ul.ie>
References: <4385155269B445AEAF27DC8639A953D7@rainbow> <20100818154130.GC9431@localhost> <565A4EE71DAC4B1A820B2748F56ABF73@rainbow> <20100819160006.GG6805@barrios-desktop> <AA3F2D89535A431DB91FE3032EDCB9EA@rainbow> <20100820053447.GA13406@localhost> <20100820093558.GG19797@csn.ul.ie> <AANLkTimVmoomDjGMCfKvNrS+v-mMnfeq6JDZzx7fjZi+@mail.gmail.com> <20100822153121.GA29389@barrios-desktop> <20100822232316.GA339@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <20100822232316.GA339@localhost>
Sender: owner-linux-mm@kvack.org
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Minchan Kim <minchan.kim@gmail.com>, Andrew Morton <akpm@linux-foundation.org>, Iram Shahzad <iram.shahzad@jp.fujitsu.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Mon, Aug 23, 2010 at 07:23:16AM +0800, Wu Fengguang wrote:
> > From: Minchan Kim <minchan.kim@gmail.com>
> > Date: Mon, 23 Aug 2010 00:20:44 +0900
> > Subject: [PATCH] compaction: handle active and inactive fairly in too_many_isolated
> > 
> > Iram reported compaction's too_many_isolated loops forever.
> > (http://www.spinics.net/lists/linux-mm/msg08123.html)
> > 
> > The meminfo of situation happened was inactive anon is zero.
> > That's because the system has no memory pressure until then.
> > While all anon pages was in active lru, compaction could select
> > active lru as well as inactive lru. That's different things
> > with vmscan's isolated. So we has been two too_many_isolated.
> > 
> > While compaction can isolated pages in both active and inactive,
> > current implementation of too_many_isolated only considers inactive.
> > It made Iram's problem.
> > 
> > This patch handles active and inactie with fair.
> > That's because we can't expect where from and how many compaction would
> > isolated pages.
> > 
> > This patch changes (nr_isolated > nr_inactive) with
> > nr_isolated > (nr_active + nr_inactive) / 2.
> 
> The change looks good, thanks. However I'm not sure if it's enough.
> 
> I wonder where the >40MB isolated pages come about.  inactive_anon
> remains 0 and free remains high over a long time, so it seems there
> are no concurrent direct reclaims at all.

When the proc trigger is used, it is not necessary for there to be any
memory pressure for compaction to be running. It's unlikely in this case
that there are many processes direct compacting but the check should
still not potentially loop.

-- 
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail191.messagelabs.com (mail191.messagelabs.com [216.82.242.19])
	by kanga.kvack.org (Postfix) with SMTP id A2D0D6B03A6
	for <linux-mm@kvack.org>; Mon, 23 Aug 2010 05:07:43 -0400 (EDT)
Received: by iwn33 with SMTP id 33so4195119iwn.14
        for <linux-mm@kvack.org>; Mon, 23 Aug 2010 02:07:42 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <20100823071610.GL19797@csn.ul.ie>
References: <20100817111018.GQ19797@csn.ul.ie>
	<4385155269B445AEAF27DC8639A953D7@rainbow>
	<20100818154130.GC9431@localhost>
	<565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
	<20100819160006.GG6805@barrios-desktop>
	<AA3F2D89535A431DB91FE3032EDCB9EA@rainbow>
	<20100820053447.GA13406@localhost>
	<20100820093558.GG19797@csn.ul.ie>
	<AANLkTimVmoomDjGMCfKvNrS+v-mMnfeq6JDZzx7fjZi+@mail.gmail.com>
	<20100822153121.GA29389@barrios-desktop>
	<20100823071610.GL19797@csn.ul.ie>
Date: Mon, 23 Aug 2010 18:07:41 +0900
Message-ID: <AANLkTikOvsH38K0j7ETOfY08AbzvfHd72otw-JTesh-4@mail.gmail.com>
Subject: Re: compaction: trying to understand the code
From: Minchan Kim <minchan.kim@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Sender: owner-linux-mm@kvack.org
To: Mel Gorman <mel@csn.ul.ie>
Cc: Andrew Morton <akpm@linux-foundation.org>, Wu Fengguang <fengguang.wu@intel.com>, Iram Shahzad <iram.shahzad@jp.fujitsu.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Mon, Aug 23, 2010 at 4:16 PM, Mel Gorman <mel@csn.ul.ie> wrote:
> On Mon, Aug 23, 2010 at 12:31:21AM +0900, Minchan Kim wrote:
>> <SNIP>
>>
>> From 560e8898295c663f02aede07b3d55880eba16c69 Mon Sep 17 00:00:00 2001
>> From: Minchan Kim <minchan.kim@gmail.com>
>> Date: Mon, 23 Aug 2010 00:20:44 +0900
>> Subject: [PATCH] compaction: handle active and inactive fairly in too_many_isolated
>>
>> Iram reported compaction's too_many_isolated loops forever.
>> (http://www.spinics.net/lists/linux-mm/msg08123.html)
>>
>> The meminfo of situation happened was inactive anon is zero.
>> That's because the system has no memory pressure until then.
>> While all anon pages was in active lru, compaction could select
>> active lru as well as inactive lru. That's different things
>> with vmscan's isolated. So we has been two too_many_isolated.
>>
>> While compaction can isolated pages in both active and inactive,
>> current implementation of too_many_isolated only considers inactive.
>> It made Iram's problem.
>>
>> This patch handles active and inactie with fair.
>> That's because we can't expect where from and how many compaction would
>> isolated pages.
>>
>> This patch changes (nr_isolated > nr_inactive) with
>> nr_isolated > (nr_active + nr_inactive) / 2.
>>
>> Cc: Mel Gorman <mel@csn.ul.ie>
>> Cc: Wu Fengguang <fengguang.wu@intel.com>
>> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
>
> Seems reasonable to me.
>
> Acked-by: Mel Gorman <mel@csn.ul.ie>

Thanks.

>
> Want to repost this as a standalone patch?

Yes. It is enough to be a standalone.
I will repost the patch as removing part about reporting Iram's problem.

We need to dig in Iram's problem regardless of this patch.

-- 
Kind regards,
Minchan Kim

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243])
	by kanga.kvack.org (Postfix) with SMTP id 0F5456B03A7
	for <linux-mm@kvack.org>; Mon, 23 Aug 2010 05:10:03 -0400 (EDT)
Received: by iwn33 with SMTP id 33so4197321iwn.14
        for <linux-mm@kvack.org>; Mon, 23 Aug 2010 02:10:02 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <C06122FE6B6044BD94C8A632B205D909@rainbow>
References: <20100817111018.GQ19797@csn.ul.ie>
	<4385155269B445AEAF27DC8639A953D7@rainbow>
	<20100818154130.GC9431@localhost>
	<565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
	<20100819160006.GG6805@barrios-desktop>
	<AA3F2D89535A431DB91FE3032EDCB9EA@rainbow>
	<20100820053447.GA13406@localhost>
	<20100820093558.GG19797@csn.ul.ie>
	<AANLkTimVmoomDjGMCfKvNrS+v-mMnfeq6JDZzx7fjZi+@mail.gmail.com>
	<20100822153121.GA29389@barrios-desktop>
	<20100822232316.GA339@localhost>
	<AANLkTim8c5C+vH1HUx-GsScirmnVoJXenLST1qQgk2bp@mail.gmail.com>
	<C06122FE6B6044BD94C8A632B205D909@rainbow>
Date: Mon, 23 Aug 2010 18:10:02 +0900
Message-ID: <AANLkTikwZtaMioEOnwTJhs-PkXWeaZhv-hYXG13n=OBX@mail.gmail.com>
Subject: Re: compaction: trying to understand the code
From: Minchan Kim <minchan.kim@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Sender: owner-linux-mm@kvack.org
To: Iram Shahzad <iram.shahzad@jp.fujitsu.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>, Mel Gorman <mel@csn.ul.ie>, Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Mon, Aug 23, 2010 at 12:03 PM, Iram Shahzad
<iram.shahzad@jp.fujitsu.com> wrote:
>> Iram. How do you execute test_app?
>>
>> 1) synchronous test
>> 1.1 start test_app
>> 1.2 wait test_app job done (ie, wait memory is fragment)
>> 1.3 echo 1 > /proc/sys/vm/compact_memory
>>
>> 2) asynchronous test
>> 2.1 start test_app
>> 2.2 not wait test_app job done
>> 2.3 echo 1 > /proc/sys/vm/compact_memory(Maybe your test app and
>> compaction were executed parallel)
>
> It's synchronous.
> First I confirm that the test app has completed its fragmentation work
> by looking at the printf output. Then only I run echo 1 >
> /proc/sys/vm/compact_memory.
>
> After completing fragmentation work, my test app sleeps in a useless while
> loop
> which I think is not important.

Thanks. It seems to be not any other processes which is entering
direct reclaiming.
I tested your test_app but failed to reproduce your problem.
Actually I suspected some leak of decrease NR_ISOLATE_XXX but my
system worked well.
And I couldn't find the point as just code reviewing. If it really
was, Mel found it during his stress test.

Hmm.. Mystery.
Maybe we need some tracepoint to debug.
-- 
Kind regards,
Minchan Kim

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227])
	by kanga.kvack.org (Postfix) with SMTP id 36BF56B03DD
	for <linux-mm@kvack.org>; Mon, 23 Aug 2010 13:14:24 -0400 (EDT)
Received: by pxi5 with SMTP id 5so2703890pxi.14
        for <linux-mm@kvack.org>; Mon, 23 Aug 2010 10:14:22 -0700 (PDT)
Date: Tue, 24 Aug 2010 02:14:16 +0900
From: Minchan Kim <minchan.kim@gmail.com>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100823171416.GA2216@barrios-desktop>
References: <4385155269B445AEAF27DC8639A953D7@rainbow>
 <20100818154130.GC9431@localhost>
 <565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
 <20100819160006.GG6805@barrios-desktop>
 <AA3F2D89535A431DB91FE3032EDCB9EA@rainbow>
 <20100820053447.GA13406@localhost>
 <20100820093558.GG19797@csn.ul.ie>
 <AANLkTimVmoomDjGMCfKvNrS+v-mMnfeq6JDZzx7fjZi+@mail.gmail.com>
 <20100822153121.GA29389@barrios-desktop>
 <20100822232316.GA339@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100822232316.GA339@localhost>
Sender: owner-linux-mm@kvack.org
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Mel Gorman <mel@csn.ul.ie>, Andrew Morton <akpm@linux-foundation.org>, Iram Shahzad <iram.shahzad@jp.fujitsu.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Mon, Aug 23, 2010 at 07:23:16AM +0800, Wu Fengguang wrote:
> > From: Minchan Kim <minchan.kim@gmail.com>
> > Date: Mon, 23 Aug 2010 00:20:44 +0900
> > Subject: [PATCH] compaction: handle active and inactive fairly in too_many_isolated
> > 
> > Iram reported compaction's too_many_isolated loops forever.
> > (http://www.spinics.net/lists/linux-mm/msg08123.html)
> > 
> > The meminfo of situation happened was inactive anon is zero.
> > That's because the system has no memory pressure until then.
> > While all anon pages was in active lru, compaction could select
> > active lru as well as inactive lru. That's different things
> > with vmscan's isolated. So we has been two too_many_isolated.
> > 
> > While compaction can isolated pages in both active and inactive,
> > current implementation of too_many_isolated only considers inactive.
> > It made Iram's problem.
> > 
> > This patch handles active and inactie with fair.
> > That's because we can't expect where from and how many compaction would
> > isolated pages.
> > 
> > This patch changes (nr_isolated > nr_inactive) with
> > nr_isolated > (nr_active + nr_inactive) / 2.
> 
> The change looks good, thanks. However I'm not sure if it's enough.
> 
> I wonder where the >40MB isolated pages come about.  inactive_anon
> remains 0 and free remains high over a long time, so it seems there
> are no concurrent direct reclaims at all. Are the pages isolated by
> the compaction process itself?

I think it can't happen without kswapd or direct reclaim.
But I think direct reclaim doesn't happen becuase Iram has no activity on system 
at that time. So just geussing following scenario.

1. trigger compaction by proc
2. isolate some pages and then migrate_pages
3. migrate_pages calls cond_resched
4. someone need big page(I am not sure this part)
4. kswapd: shrink anon active list due to inactive_anon_is_low
5. kswapd: isolate_lru_pages for order > 0 (ex, 0.5M page) so 0.5 M * 32 = 16M are isolated
6. kswapd: shrink_zone : shrink anon active list due to inactive_anon_is_low 
7. kswapd: isolate_lru_pages for order > 0 (ex, 0.5M page) so 0.5 M * 32  are isolated again.

Does it make sense?

-- 
Kind regards,
Minchan Kim

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243])
	by kanga.kvack.org (Postfix) with SMTP id 40A4460080B
	for <linux-mm@kvack.org>; Mon, 23 Aug 2010 20:27:54 -0400 (EDT)
Date: Tue, 24 Aug 2010 08:27:53 +0800
From: Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100824002753.GB6568@localhost>
References: <20100818154130.GC9431@localhost>
 <565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
 <20100819160006.GG6805@barrios-desktop>
 <AA3F2D89535A431DB91FE3032EDCB9EA@rainbow>
 <20100820053447.GA13406@localhost>
 <20100820093558.GG19797@csn.ul.ie>
 <AANLkTimVmoomDjGMCfKvNrS+v-mMnfeq6JDZzx7fjZi+@mail.gmail.com>
 <20100822153121.GA29389@barrios-desktop>
 <20100822232316.GA339@localhost>
 <20100823171416.GA2216@barrios-desktop>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100823171416.GA2216@barrios-desktop>
Sender: owner-linux-mm@kvack.org
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Mel Gorman <mel@csn.ul.ie>, Andrew Morton <akpm@linux-foundation.org>, Iram Shahzad <iram.shahzad@jp.fujitsu.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Tue, Aug 24, 2010 at 01:14:16AM +0800, Minchan Kim wrote:
> On Mon, Aug 23, 2010 at 07:23:16AM +0800, Wu Fengguang wrote:
> > > From: Minchan Kim <minchan.kim@gmail.com>
> > > Date: Mon, 23 Aug 2010 00:20:44 +0900
> > > Subject: [PATCH] compaction: handle active and inactive fairly in too_many_isolated
> > > 
> > > Iram reported compaction's too_many_isolated loops forever.
> > > (http://www.spinics.net/lists/linux-mm/msg08123.html)
> > > 
> > > The meminfo of situation happened was inactive anon is zero.
> > > That's because the system has no memory pressure until then.
> > > While all anon pages was in active lru, compaction could select
> > > active lru as well as inactive lru. That's different things
> > > with vmscan's isolated. So we has been two too_many_isolated.
> > > 
> > > While compaction can isolated pages in both active and inactive,
> > > current implementation of too_many_isolated only considers inactive.
> > > It made Iram's problem.
> > > 
> > > This patch handles active and inactie with fair.
> > > That's because we can't expect where from and how many compaction would
> > > isolated pages.
> > > 
> > > This patch changes (nr_isolated > nr_inactive) with
> > > nr_isolated > (nr_active + nr_inactive) / 2.
> > 
> > The change looks good, thanks. However I'm not sure if it's enough.
> > 
> > I wonder where the >40MB isolated pages come about.  inactive_anon
> > remains 0 and free remains high over a long time, so it seems there
> > are no concurrent direct reclaims at all. Are the pages isolated by
> > the compaction process itself?
> 
> I think it can't happen without kswapd or direct reclaim.
> But I think direct reclaim doesn't happen becuase Iram has no activity on system 
> at that time. So just geussing following scenario.
> 
> 1. trigger compaction by proc
> 2. isolate some pages and then migrate_pages
> 3. migrate_pages calls cond_resched
> 4. someone need big page(I am not sure this part)
> 4. kswapd: shrink anon active list due to inactive_anon_is_low
> 5. kswapd: isolate_lru_pages for order > 0 (ex, 0.5M page) so 0.5 M * 32 = 16M are isolated
> 6. kswapd: shrink_zone : shrink anon active list due to inactive_anon_is_low 
> 7. kswapd: isolate_lru_pages for order > 0 (ex, 0.5M page) so 0.5 M * 32  are isolated again.
> 
> Does it make sense?

One question is, why kswapd won't proceed after isolating all the pages?
If it has done with the isolated pages, we'll see growing inactive_anon
numbers.

/proc/vmstat should give more clues on any possible page reclaim
activities. Iram, would you help post it?

Thanks,
Fengguang

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227])
	by kanga.kvack.org (Postfix) with SMTP id 9F32660080F
	for <linux-mm@kvack.org>; Tue, 24 Aug 2010 01:02:42 -0400 (EDT)
Received: from m2.gw.fujitsu.co.jp ([10.0.50.72])
	by fgwmail5.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id o7O52Wuv027403
	for <linux-mm@kvack.org> (envelope-from iram.shahzad@jp.fujitsu.com);
	Tue, 24 Aug 2010 14:02:32 +0900
Received: from smail (m2 [127.0.0.1])
	by outgoing.m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 6B50145DE55
	for <linux-mm@kvack.org>; Tue, 24 Aug 2010 14:02:32 +0900 (JST)
Received: from s2.gw.fujitsu.co.jp (s2.gw.fujitsu.co.jp [10.0.50.92])
	by m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 4935945DE51
	for <linux-mm@kvack.org>; Tue, 24 Aug 2010 14:02:32 +0900 (JST)
Received: from s2.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id 2D19E1DB803F
	for <linux-mm@kvack.org>; Tue, 24 Aug 2010 14:02:32 +0900 (JST)
Received: from ml14.s.css.fujitsu.com (ml14.s.css.fujitsu.com [10.249.87.104])
	by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id D3FD41DB803B
	for <linux-mm@kvack.org>; Tue, 24 Aug 2010 14:02:31 +0900 (JST)
Message-ID: <8E31CE28A1354C43BBAD0BDEFA10494E@rainbow>
From: "Iram Shahzad" <iram.shahzad@jp.fujitsu.com>
References: <20100818154130.GC9431@localhost> <565A4EE71DAC4B1A820B2748F56ABF73@rainbow> <20100819160006.GG6805@barrios-desktop> <AA3F2D89535A431DB91FE3032EDCB9EA@rainbow> <20100820053447.GA13406@localhost> <20100820093558.GG19797@csn.ul.ie> <AANLkTimVmoomDjGMCfKvNrS+v-mMnfeq6JDZzx7fjZi+@mail.gmail.com> <20100822153121.GA29389@barrios-desktop> <20100822232316.GA339@localhost> <20100823171416.GA2216@barrios-desktop> <20100824002753.GB6568@localhost>
Subject: Re: compaction: trying to understand the code
Date: Tue, 24 Aug 2010 14:07:02 +0900
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_008E_01CB4395.9FD537D0"
Sender: owner-linux-mm@kvack.org
To: Wu Fengguang <fengguang.wu@intel.com>, Minchan Kim <minchan.kim@gmail.com>
Cc: Mel Gorman <mel@csn.ul.ie>, Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

This is a multi-part message in MIME format.

------=_NextPart_000_008E_01CB4395.9FD537D0
Content-Type: text/plain;
	format=flowed;
	charset="ISO-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit

> One question is, why kswapd won't proceed after isolating all the pages?
> If it has done with the isolated pages, we'll see growing inactive_anon
> numbers.
> 
> /proc/vmstat should give more clues on any possible page reclaim
> activities. Iram, would you help post it?

I am not sure which point of time are you interested in, so I am
attaching /proc/vmstat log of 3 points.

too_many_isolated_vmstat_before_frag.txt
   This one is taken before I ran my test app which attempts
   to make fragmentation
too_many_isolated_vmstat_before_compaction.txt
   This one is taken after running the test app and before
   running compaction.
too_many_isolated_vmstat_during_compaction.txt
   This one is taken a few minutes after running compaction.
   To take this I ran compaction in background.

Thanks
Iram

------=_NextPart_000_008E_01CB4395.9FD537D0
Content-Type: text/plain;
	format=flowed;
	name="too_many_isolated_vmstat_before_frag.txt";
	reply-type=original
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="too_many_isolated_vmstat_before_frag.txt"

nr_free_pages 79896
nr_inactive_anon 0
nr_active_anon 14688
nr_inactive_file 10444
nr_active_file 2718
nr_unevictable 0
nr_mlock 0
nr_anon_pages 12341
nr_mapped 9430
nr_file_pages 15511
nr_dirty 0
nr_writeback 0
nr_slab_reclaimable 528
nr_slab_unreclaimable 1073
nr_page_table_pages 1479
nr_kernel_stack 235
nr_unstable 0
nr_bounce 0
nr_vmscan_write 0
nr_writeback_temp 0
nr_isolated_anon 0
nr_isolated_file 0
nr_shmem 2349
pgpgin 4
pgpgout 0
pswpin 0
pswpout 0
pgalloc_normal 54208
pgalloc_high 0
pgalloc_movable 0
pgfree 134220
pgactivate 2718
pgdeactivate 0
pgfault 88952
pgmajfault 555
pgrefill_normal 0
pgrefill_high 0
pgrefill_movable 0
pgsteal_normal 0
pgsteal_high 0
pgsteal_movable 0
pgscan_kswapd_normal 0
pgscan_kswapd_high 0
pgscan_kswapd_movable 0
pgscan_direct_normal 0
pgscan_direct_high 0
pgscan_direct_movable 0
pginodesteal 0
slabs_scanned 0
kswapd_steal 0
kswapd_inodesteal 0
pageoutrun 0
allocstall 0
pgrotated 0
compact_blocks_moved 0
compact_pages_moved 0
compact_pagemigrate_failed 0
compact_stall 0
compact_fail 0
compact_success 0
unevictable_pgs_culled 0
unevictable_pgs_scanned 0
unevictable_pgs_rescued 0
unevictable_pgs_mlocked 0
unevictable_pgs_munlocked 0
unevictable_pgs_cleared 0
unevictable_pgs_stranded 0
unevictable_pgs_mlockfreed 0

------=_NextPart_000_008E_01CB4395.9FD537D0
Content-Type: text/plain;
	format=flowed;
	name="too_many_isolated_vmstat_before_compaction.txt";
	reply-type=original
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="too_many_isolated_vmstat_before_compaction.txt"

nr_free_pages 54098
nr_inactive_anon 0
nr_active_anon 40354
nr_inactive_file 10433
nr_active_file 2729
nr_unevictable 0
nr_mlock 0
nr_anon_pages 38007
nr_mapped 9469
nr_file_pages 15511
nr_dirty 0
nr_writeback 0
nr_slab_reclaimable 528
nr_slab_unreclaimable 1070
nr_page_table_pages 1582
nr_kernel_stack 236
nr_unstable 0
nr_bounce 0
nr_vmscan_write 0
nr_writeback_temp 0
nr_isolated_anon 0
nr_isolated_file 0
nr_shmem 2349
pgpgin 4
pgpgout 0
pswpin 0
pswpout 0
pgalloc_normal 105927
pgalloc_high 0
pgalloc_movable 0
pgfree 160167
pgactivate 2729
pgdeactivate 0
pgfault 141220
pgmajfault 555
pgrefill_normal 0
pgrefill_high 0
pgrefill_movable 0
pgsteal_normal 0
pgsteal_high 0
pgsteal_movable 0
pgscan_kswapd_normal 0
pgscan_kswapd_high 0
pgscan_kswapd_movable 0
pgscan_direct_normal 0
pgscan_direct_high 0
pgscan_direct_movable 0
pginodesteal 0
slabs_scanned 0
kswapd_steal 0
kswapd_inodesteal 0
pageoutrun 0
allocstall 0
pgrotated 0
compact_blocks_moved 0
compact_pages_moved 0
compact_pagemigrate_failed 0
compact_stall 0
compact_fail 0
compact_success 0
unevictable_pgs_culled 0
unevictable_pgs_scanned 0
unevictable_pgs_rescued 0
unevictable_pgs_mlocked 0
unevictable_pgs_munlocked 0
unevictable_pgs_cleared 0
unevictable_pgs_stranded 0
unevictable_pgs_mlockfreed 0

------=_NextPart_000_008E_01CB4395.9FD537D0
Content-Type: text/plain;
	format=flowed;
	name="too_many_isolated_vmstat_during_compaction.txt";
	reply-type=original
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="too_many_isolated_vmstat_during_compaction.txt"

nr_free_pages 53673
nr_inactive_anon 0
nr_active_anon 40498
nr_inactive_file 10427
nr_active_file 2735
nr_unevictable 0
nr_mlock 0
nr_anon_pages 38151
nr_mapped 9469
nr_file_pages 15511
nr_dirty 0
nr_writeback 0
nr_slab_reclaimable 536
nr_slab_unreclaimable 1070
nr_page_table_pages 1588
nr_kernel_stack 237
nr_unstable 0
nr_bounce 0
nr_vmscan_write 0
nr_writeback_temp 0
nr_isolated_anon 8592
nr_isolated_file 1862
nr_shmem 2349
pgpgin 4
pgpgout 0
pswpin 0
pswpout 0
pgalloc_normal 117872
pgalloc_high 0
pgalloc_movable 0
pgfree 182402
pgactivate 2735
pgdeactivate 0
pgfault 182499
pgmajfault 555
pgrefill_normal 0
pgrefill_high 0
pgrefill_movable 0
pgsteal_normal 0
pgsteal_high 0
pgsteal_movable 0
pgscan_kswapd_normal 0
pgscan_kswapd_high 0
pgscan_kswapd_movable 0
pgscan_direct_normal 0
pgscan_direct_high 0
pgscan_direct_movable 0
pginodesteal 0
slabs_scanned 0
kswapd_steal 0
kswapd_inodesteal 0
pageoutrun 0
allocstall 0
pgrotated 0
compact_blocks_moved 327
compact_pages_moved 10454
compact_pagemigrate_failed 0
compact_stall 0
compact_fail 0
compact_success 0
unevictable_pgs_culled 0
unevictable_pgs_scanned 0
unevictable_pgs_rescued 0
unevictable_pgs_mlocked 0
unevictable_pgs_munlocked 0
unevictable_pgs_cleared 0
unevictable_pgs_stranded 0
unevictable_pgs_mlockfreed 0

------=_NextPart_000_008E_01CB4395.9FD537D0--


--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227])
	by kanga.kvack.org (Postfix) with SMTP id 97C526008D8
	for <linux-mm@kvack.org>; Tue, 24 Aug 2010 02:52:40 -0400 (EDT)
Received: by ywo7 with SMTP id 7so3100701ywo.14
        for <linux-mm@kvack.org>; Mon, 23 Aug 2010 23:52:38 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <8E31CE28A1354C43BBAD0BDEFA10494E@rainbow>
References: <20100818154130.GC9431@localhost>
	<565A4EE71DAC4B1A820B2748F56ABF73@rainbow>
	<20100819160006.GG6805@barrios-desktop>
	<AA3F2D89535A431DB91FE3032EDCB9EA@rainbow>
	<20100820053447.GA13406@localhost>
	<20100820093558.GG19797@csn.ul.ie>
	<AANLkTimVmoomDjGMCfKvNrS+v-mMnfeq6JDZzx7fjZi+@mail.gmail.com>
	<20100822153121.GA29389@barrios-desktop>
	<20100822232316.GA339@localhost>
	<20100823171416.GA2216@barrios-desktop>
	<20100824002753.GB6568@localhost>
	<8E31CE28A1354C43BBAD0BDEFA10494E@rainbow>
Date: Tue, 24 Aug 2010 15:52:37 +0900
Message-ID: <AANLkTikTu3jx5WyYEDZY2mk99V+w7kxL5k7xJDS+QZ+m@mail.gmail.com>
Subject: Re: compaction: trying to understand the code
From: Minchan Kim <minchan.kim@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: owner-linux-mm@kvack.org
To: Iram Shahzad <iram.shahzad@jp.fujitsu.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>, Mel Gorman <mel@csn.ul.ie>, Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Tue, Aug 24, 2010 at 2:07 PM, Iram Shahzad
<iram.shahzad@jp.fujitsu.com> wrote:
>> One question is, why kswapd won't proceed after isolating all the pages?
>> If it has done with the isolated pages, we'll see growing inactive_anon
>> numbers.
>>
>> /proc/vmstat should give more clues on any possible page reclaim
>> activities. Iram, would you help post it?
>
> I am not sure which point of time are you interested in, so I am
> attaching /proc/vmstat log of 3 points.
>
> too_many_isolated_vmstat_before_frag.txt
> =A0This one is taken before I ran my test app which attempts
> =A0to make fragmentation
> too_many_isolated_vmstat_before_compaction.txt
> =A0This one is taken after running the test app and before
> =A0running compaction.
> too_many_isolated_vmstat_during_compaction.txt
> =A0This one is taken a few minutes after running compaction.
> =A0To take this I ran compaction in background.
>
> Thanks
> Iram
>

Hmm.. Never happens reclaim. Strange.
In addtion, pgpgin is always 4.

pgpgin 4
pgpgout 0

Is it possible?
What kinds of filesystem do you use?
Do you boot from NFS?
Do your system have any non-mainline(ie, doesn't merged into linux
kernel tree) driver, file system or any feature?

Maybe your config file can answer this questions.
Thanks.
--=20
Kind regards,
Minchan Kim

--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51])
	by kanga.kvack.org (Postfix) with SMTP id 351016B01F1
	for <linux-mm@kvack.org>; Thu, 26 Aug 2010 04:01:09 -0400 (EDT)
Received: from m5.gw.fujitsu.co.jp ([10.0.50.75])
	by fgwmail7.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id o7Q816QJ021152
	for <linux-mm@kvack.org> (envelope-from iram.shahzad@jp.fujitsu.com);
	Thu, 26 Aug 2010 17:01:06 +0900
Received: from smail (m5 [127.0.0.1])
	by outgoing.m5.gw.fujitsu.co.jp (Postfix) with ESMTP id 3AE9045DE51
	for <linux-mm@kvack.org>; Thu, 26 Aug 2010 17:01:06 +0900 (JST)
Received: from s5.gw.fujitsu.co.jp (s5.gw.fujitsu.co.jp [10.0.50.95])
	by m5.gw.fujitsu.co.jp (Postfix) with ESMTP id 1223845DE56
	for <linux-mm@kvack.org>; Thu, 26 Aug 2010 17:01:06 +0900 (JST)
Received: from s5.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s5.gw.fujitsu.co.jp (Postfix) with ESMTP id EFCB41DB805D
	for <linux-mm@kvack.org>; Thu, 26 Aug 2010 17:01:05 +0900 (JST)
Received: from m108.s.css.fujitsu.com (m108.s.css.fujitsu.com [10.249.87.108])
	by s5.gw.fujitsu.co.jp (Postfix) with ESMTP id 98CCC1DB8060
	for <linux-mm@kvack.org>; Thu, 26 Aug 2010 17:01:05 +0900 (JST)
Message-ID: <132D72DD90BB458D8F0CF2D58C019517@rainbow>
From: "Iram Shahzad" <iram.shahzad@jp.fujitsu.com>
References: <20100818154130.GC9431@localhost><565A4EE71DAC4B1A820B2748F56ABF73@rainbow><20100819160006.GG6805@barrios-desktop><AA3F2D89535A431DB91FE3032EDCB9EA@rainbow><20100820053447.GA13406@localhost><20100820093558.GG19797@csn.ul.ie><AANLkTimVmoomDjGMCfKvNrS+v-mMnfeq6JDZzx7fjZi+@mail.gmail.com><20100822153121.GA29389@barrios-desktop><20100822232316.GA339@localhost><20100823171416.GA2216@barrios-desktop><20100824002753.GB6568@localhost><8E31CE28A1354C43BBAD0BDEFA10494E@rainbow> <AANLkTikTu3jx5WyYEDZY2mk99V+w7kxL5k7xJDS+QZ+m@mail.gmail.com>
Subject: Re: compaction: trying to understand the code
Date: Thu, 26 Aug 2010 17:05:41 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="ISO-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mm@kvack.org
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>, Mel Gorman <mel@csn.ul.ie>, Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

> What kinds of filesystem do you use?
> Do you boot from NFS?
> Do your system have any non-mainline(ie, doesn't merged into linux
> kernel tree) driver, file system or any feature?


I do not boot from NFS.
My system does have non-mainline file system and drivers.
I thought file system and drivers were irrelevant to this problem,
are they?

Thanks
Iram


--
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>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51])
	by kanga.kvack.org (Postfix) with ESMTP id 6136C6B01F1
	for <linux-mm@kvack.org>; Thu, 26 Aug 2010 04:51:23 -0400 (EDT)
Date: Thu, 26 Aug 2010 09:51:05 +0100
From: Mel Gorman <mel@csn.ul.ie>
Subject: Re: compaction: trying to understand the code
Message-ID: <20100826085105.GB20944@csn.ul.ie>
References: <20100819160006.GG6805@barrios-desktop> <AA3F2D89535A431DB91FE3032EDCB9EA@rainbow> <20100820053447.GA13406@localhost> <20100820093558.GG19797@csn.ul.ie> <AANLkTimVmoomDjGMCfKvNrS+v-mMnfeq6JDZzx7fjZi+@mail.gmail.com> <20100822153121.GA29389@barrios-desktop> <20100822232316.GA339@localhost> <AANLkTim8c5C+vH1HUx-GsScirmnVoJXenLST1qQgk2bp@mail.gmail.com> <C06122FE6B6044BD94C8A632B205D909@rainbow> <AANLkTikwZtaMioEOnwTJhs-PkXWeaZhv-hYXG13n=OBX@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <AANLkTikwZtaMioEOnwTJhs-PkXWeaZhv-hYXG13n=OBX@mail.gmail.com>
Sender: owner-linux-mm@kvack.org
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Iram Shahzad <iram.shahzad@jp.fujitsu.com>, Wu Fengguang <fengguang.wu@intel.com>, Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
List-ID: <linux-mm.kvack.org>

On Mon, Aug 23, 2010 at 06:10:02PM +0900, Minchan Kim wrote:
> On Mon, Aug 23, 2010 at 12:03 PM, Iram Shahzad
> <iram.shahzad@jp.fujitsu.com> wrote:
> >> Iram. How do you execute test_app?
> >>
> >> 1) synchronous test
> >> 1.1 start test_app
> >> 1.2 wait test_app job done (ie, wait memory is fragment)
> >> 1.3 echo 1 > /proc/sys/vm/compact_memory
> >>
> >> 2) asynchronous test
> >> 2.1 start test_app
> >> 2.2 not wait test_app job done
> >> 2.3 echo 1 > /proc/sys/vm/compact_memory(Maybe your test app and
> >> compaction were executed parallel)
> >
> > It's synchronous.
> > First I confirm that the test app has completed its fragmentation work
> > by looking at the printf output. Then only I run echo 1 >
> > /proc/sys/vm/compact_memory.
> >
> > After completing fragmentation work, my test app sleeps in a useless while
> > loop
> > which I think is not important.
> 
> Thanks. It seems to be not any other processes which is entering
> direct reclaiming.
> I tested your test_app but failed to reproduce your problem.
> Actually I suspected some leak of decrease NR_ISOLATE_XXX but my
> system worked well.
> And I couldn't find the point as just code reviewing. If it really
> was, Mel found it during his stress test.
> 

My test machines have been tied up which has delayed me reviewing these
patches. I reran standardish compaction stress tests and didn't spot a
NR_ISOLATE_XXX. While none of those tests depend on the proc trigger,
they share the core logic so I don't think we're looking at a leak issue
and all the difficulty is in too_many_isolated()

-- 
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>