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@xxxxxxxxxxxxxx> 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@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>