On 08/16/2016 08:07 AM, Joonsoo Kim wrote:
Signed-off-by: Vlastimil Babka <vbabka@xxxxxxx> --- mm/page_alloc.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index fb975cec3518..b28517b918b0 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3155,13 +3155,8 @@ should_compact_retry(struct alloc_context *ac, int order, int alloc_flags, * so it doesn't really make much sense to retry except when the * failure could be caused by insufficient priority */ - if (compaction_failed(compact_result)) { - if (*compact_priority > MIN_COMPACT_PRIORITY) { - (*compact_priority)--; - return true; - } - return false; - } + if (compaction_failed(compact_result)) + goto check_priority; /* * make sure the compaction wasn't deferred or didn't bail out early @@ -3185,6 +3180,15 @@ should_compact_retry(struct alloc_context *ac, int order, int alloc_flags, if (compaction_retries <= max_retries) return true; + /* + * Make sure there is at least one attempt at the highest priority + * if we exhausted all retries at the lower priorities + */ +check_priority: + if (*compact_priority > MIN_COMPACT_PRIORITY) { + (*compact_priority)--; + return true; + } return false;The only difference that this patch makes is increasing priority when COMPACT_PARTIAL(COMPACTION_SUCCESS) returns. In that case, we can
Hm it's true that I adjusted this patch from the previous version, before realizing that PARTIAL is now SUCCESS.
usually allocate high-order freepage so we would not enter here. Am I missing something? Is it really needed behaviour change?
It will likely be rare when this triggers, when compaction success doesn't lead to allocation success due to parallel allocation activity.
Thanks.
-- 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>