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