On 05/10/2016 09:36 AM, Vlastimil Babka wrote:
> /*
> - * compaction considers all the zone as desperately out of memory
> - * so it doesn't really make much sense to retry except when the
> - * failure could be caused by insufficient priority
> + * Compaction backed off due to watermark checks for order-0
> + * so the regular reclaim has to try harder and reclaim something
> + * Retry only if it looks like reclaim might have a chance.
> */
> - if (compaction_failed(compact_result)) {
> - if (*compact_priority > 0) {
> - (*compact_priority)--;
> - return true;
> - }
> - return false;
> - }
Oops, looks like my editing resulted in compaction_failed() check to be
removed completely, which wasn't intentional and can lead to infinite
loops. This should be added on top.
----8<----
>From 59a2b38689aa451f661c964dc9bfb990736ad92d Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <vba...@suse.cz>
Date: Tue, 10 May 2016 14:51:03 +0200
Subject: [PATCH 15/15] fixup! mm, compaction: more reliably increase direct
compaction priority
---
mm/page_alloc.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index fa49eb4a5919..e8a0d33cfb67 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3268,6 +3268,14 @@ should_compact_retry(struct alloc_context *ac, int
order, int alloc_flags,
}
/*
+ * Compaction considers all the zones as unfixably fragmented and we
+ * are on the highest priority, which means it can't be due to
+ * heuristics and it doesn't really make much sense to retry.
+ */
+ if (compaction_failed(compact_result))
+ return false;
+
+ /*
* The remaining possibility is that compaction made progress and
* created a high-order page, but it was allocated by somebody else.
* To prevent thrashing, limit the number of retries in such case.
--
2.8.2
