On 06/05/2013 11:10 AM, 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.
Won't kswapd reset compaction even with your patch, but only when kswapd invokes compaction and the cursors meet? In other words, the behaviour should be correct even for cases where kswapd is the only thing in the system doing compaction (eg. GFP_ATOMIC higher order allocations), but your changelog does not describe it completely.
This decreased reliability of compaction was introduced in commit 62997027ca5b3d4618198ed8b1aba40b61b1137b . Signed-off-by: Andrea Arcangeli <aarcange@xxxxxxxxxx>
The code looks good to me. Reviewed-by: Rik van Riel <riel@xxxxxxxxxx> -- All rights reversed -- 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>