linux-kernel - [RFC][PATCH] mm: couple rcu and memory reclaim

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-next>] [day] [month] [year] [list]

Date:	Mon, 24 Sep 2007 10:45:17 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org
Cc:	Nick Piggin <nickpiggin@...oo.com.au>,
	Rik van Riel <riel@...hat.com>
Subject: [RFC][PATCH] mm: couple rcu and memory reclaim

Just an idea I had, it seems like a good idea to wait for RCU callbacks
in reclaim so that we won't get all of memory stuck there.

If this location is too aggressive we might stick it next to
disable_swap_token().

---
Couple RCU and reclaim.

There could be a lot of memory stuck in RCU callbacks. Wait for RCU to
finish before giving it another go.

Placed in kswapd and not direct reclaim path because kswapd never holds
rcu_read_lock() at this point and can thus not deadlock. Direct reclaim
callers might hold rcu_read_lock() and would suffer from deadlocks if
sync_rcu() were to be called.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
---
 mm/vmscan.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Index: linux-2.6/mm/vmscan.c
===================================================================
--- linux-2.6.orig/mm/vmscan.c
+++ linux-2.6/mm/vmscan.c
@@ -1435,8 +1435,10 @@ loop_again:
 		unsigned long lru_pages = 0;

 		/* The swap token gets in the way of swapout... */
-		if (!priority)
+		if (!priority) {
+			synchronize_rcu();
 			disable_swap_token();
+		}

 		all_zones_ok = 1;

-
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/