summaryrefslogtreecommitdiff
path: root/mm
diff options
context:
space:
mode:
authorKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>2009-01-06 14:40:33 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2009-01-06 15:59:10 -0800
commit73ce02e96fe34a983199a9855b2ae738f960a6ee (patch)
tree06dbbc2c38d55f8eacab09c55a68c736156b9540 /mm
parent594fe1a044325bb0a1a49ca7d086e3df4f1df59a (diff)
downloadlinux-3.10-73ce02e96fe34a983199a9855b2ae738f960a6ee.tar.gz
linux-3.10-73ce02e96fe34a983199a9855b2ae738f960a6ee.tar.bz2
linux-3.10-73ce02e96fe34a983199a9855b2ae738f960a6ee.zip
mm: stop kswapd's infinite loop at high order allocation
Wassim Dagash reported following kswapd infinite loop problem. kswapd runs in some infinite loop trying to swap until order 10 of zone highmem is OK.... kswapd will continue to try to balance order 10 of zone highmem forever (or until someone release a very large chunk of highmem). For non order-0 allocations, the system may never be balanced due to fragmentation but kswapd should not infinitely loop as a result. Instead, recheck all watermarks at order-0 as they are the most important. If watermarks are ok, kswapd will go back to sleep. [akpm@linux-foundation.org: fix comment] Reported-by: wassim dagash <wassim.dagash@gmail.com> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Reviewed-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Mel Gorman <mel@csn.ul.ie> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm')
-rw-r--r--mm/vmscan.c17
1 files changed, 17 insertions, 0 deletions
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 5daf606e0a3..b07c48b09a9 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1867,6 +1867,23 @@ out:
try_to_freeze();
+ /*
+ * Fragmentation may mean that the system cannot be
+ * rebalanced for high-order allocations in all zones.
+ * At this point, if nr_reclaimed < SWAP_CLUSTER_MAX,
+ * it means the zones have been fully scanned and are still
+ * not balanced. For high-order allocations, there is
+ * little point trying all over again as kswapd may
+ * infinite loop.
+ *
+ * Instead, recheck all watermarks at order-0 as they
+ * are the most important. If watermarks are ok, kswapd will go
+ * back to sleep. High-order users can still perform direct
+ * reclaim if they wish.
+ */
+ if (sc.nr_reclaimed < SWAP_CLUSTER_MAX)
+ order = sc.order = 0;
+
goto loop_again;
}