Re: compaction: trying to understand the code

[Mel Gorman <mel@csn.ul.ie>]

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>