On Wed, Jun 05, 2013 at 05:10:33PM +0200, Andrea Arcangeli wrote: > If kswapd never need to run (only __GFP_NO_KSWAPD allocations and > plenty of free memory) compaction is otherwise crippled down and stops > running for a while after the free/isolation cursor meets. After that > allocation can fail for a full cycle of compaction_deferred, until > compaction_restarting finally reset it again. > > Stopping compaction for a full cycle after the cursor meets, even if > it never failed and it's not going to fail, doesn't make sense. > > We already throttle compaction CPU utilization using > defer_compaction. We shouldn't prevent compaction to run after each > pass completes when the cursor meets, unless it failed. > > This makes direct compaction functional again. The throttling of > direct compaction is still controlled by the defer_compaction > logic. > > kswapd still won't risk to reset compaction, and it will wait direct > compaction to do so. Not sure if this is ideal but it at least > decreases the risk of kswapd doing too much work. kswapd will only run > one pass of compaction until some allocation invokes compaction again. > > This decreased reliability of compaction was introduced in commit > 62997027ca5b3d4618198ed8b1aba40b61b1137b . > > Signed-off-by: Andrea Arcangeli <aarcange@xxxxxxxxxx> That was part of a series that addressed a problem where processes stalled for prolonged periods of time in compaction. I see your point and I do not have a better suggestion at this time but I'll keep an eye out for regressions in that area. Acked-by: Mel Gorman <mgorman@xxxxxxx> -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>