linux-kernel - [PATCH] mm: stop kswapd's infinite loop at high order allocation take2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090101021240.A057.KOSAKI.MOTOHIRO@jp.fujitsu.com>
Date:	Thu, 1 Jan 2009 23:52:02 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Mel Gorman <mel@....ul.ie>
Cc:	kosaki.motohiro@...fujitsu.com,
	LKML <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Nick Piggin <npiggin@...e.de>,
	wassim dagash <wassim.dagash@...il.com>
Subject: [PATCH] mm: stop kswapd's infinite loop at high order allocation take2


> >                 /*
> >                  * 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 direct reclaim
> >                  * if they wish.
> >                  */
> > 
> > ?
> 
> Excellent. I strongly like this and I hope merge it to my patch.
> I'll resend new patch.

Done.



==
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Subject: [PATCH] mm: kswapd stop 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. 


Reported-by: wassim dagash <wassim.dagash@...il.com>
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Reviewed-by: Nick Piggin <npiggin@...e.de>
Signed-off-by: Mel Gorman <mel@....ul.ie>,
---
 mm/vmscan.c |   17 +++++++++++++++++
 1 file changed, 17 insertions(+)

Index: b/mm/vmscan.c
===================================================================
--- a/mm/vmscan.c	2008-12-25 08:26:37.000000000 +0900
+++ b/mm/vmscan.c	2009-01-01 01:56:02.000000000 +0900
@@ -1872,6 +1872,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 direct reclaim
+		 * if they wish.
+		 */
+		if (nr_reclaimed < SWAP_CLUSTER_MAX)
+			order = sc.order = 0;
+
 		goto loop_again;
 	}
 



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/