From: David Rientjes <rient...@google.com>
We've been getting warnings about an excessive amount of time spent
allocating pages for migration during memory compaction without
scheduling. isolate_freepages_block() already periodically checks for
contended locks or the need to schedule, but isolate_freepages() never
does.
When a zone is massively long and no suitable targets can be found, this
iteration can be quite expensive without ever doing cond_resched().
Check periodically for the need to reschedule while the compaction free
scanner iterates.
Signed-off-by: David Rientjes <rient...@google.com>
Reviewed-by: Rik van Riel <r...@redhat.com>
Reviewed-by: Wanpeng Li <liw...@linux.vnet.ibm.com>
Acked-by: Mel Gorman <mgor...@suse.de>
Signed-off-by: Andrew Morton <a...@linux-foundation.org>
Signed-off-by: Linus Torvalds <torva...@linux-foundation.org>
(cherry picked from commit f6ea3adb70b20ae36277a1b0eaaf4da9f6479a28)
Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com>
---
mm/compaction.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/mm/compaction.c b/mm/compaction.c
index 63f5f4627ea7..f693bf3b87e2 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -698,6 +698,13 @@ static void isolate_freepages(struct zone *zone,
unsigned long isolated;
unsigned long end_pfn;
+ /*
+ * This can iterate a massively long zone without finding any
+ * suitable migration targets, so periodically check if we need
+ * to schedule.
+ */
+ cond_resched();
+
if (!pfn_valid(pfn))
continue;
--
2.13.6
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
