On Tue 10-05-16 09:36:02, Vlastimil Babka wrote: > During reclaim/compaction loop, compaction priority can be increased by the > should_compact_retry() function, but the current code is not optimal for > several reasons: > > - priority is only increased when compaction_failed() is true, which means > that compaction has scanned the whole zone. This may not happen even after > multiple attempts with the lower priority due to parallel activity, so we > might needlessly struggle on the lower priority. OK, I can see that this can be changed if we have a guarantee that at least one full round is guaranteed. Which seems to be the case for the lowest priority. > > - should_compact_retry() is only called when should_reclaim_retry() returns > false. This means that compaction priority cannot get increased as long > as reclaim makes sufficient progress. Theoretically, reclaim should stop > retrying for high-order allocations as long as the high-order page doesn't > exist but due to races, this may result in spurious retries when the > high-order page momentarily does exist. This is intentional behavior and I would like to preserve it if it is possible. For higher order pages should_reclaim_retry retries as long as there are some eligible high order pages present which are just hidden by the watermark check. So this is mostly to get us over watermarks to start carrying about fragmentation. If we race there then nothing really terrible should happen and we should eventually converge to a terminal state. Does this make sense to you? -- Michal Hocko 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>