linux-kernel - Re: [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-prev] [day] [month] [year] [list]

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

On Monday 24 September 2007 18:45, Peter Zijlstra wrote:
> 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.

I think it would be much too aggressive (_especially_ with preemptible
RCU, I would have thought?). And not just for the case of adding a lot
of idle time while other CPUs are busy not being preempted -- also
that if you have lots of CPUs reclaiming and asking to synchronize_rcu,
then you could have global RCU state getting ping-ponged.

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

I don't see a really good reason to add this kind of wait here. I mean,
we have to wait for RCU anyway, so we may as well scan what we can
until then?

Putting it in a slowpath at some point when we think we're heading for
OOM I think would be a bit better.
-
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/