linux-kernel - Re: [PATCH RFC tip/core/rcu 05/41] rcu: Avoid waking up CPUs having only kfree

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]

Date:	Wed, 1 Feb 2012 17:15:52 -0800
From:	Josh Triplett <josh@...htriplett.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	mathieu.desnoyers@...ymtl.ca, niv@...ibm.com, tglx@...utronix.de,
	peterz@...radead.org, rostedt@...dmis.org, Valdis.Kletnieks@...edu,
	dhowells@...hat.com, eric.dumazet@...il.com, darren@...art.com,
	fweisbec@...il.com, patches@...aro.org,
	"Paul E. McKenney" <paul.mckenney@...aro.org>
Subject: Re: [PATCH RFC tip/core/rcu 05/41] rcu: Avoid waking up CPUs having
 only kfree_rcu() callbacks

On Wed, Feb 01, 2012 at 11:41:23AM -0800, Paul E. McKenney wrote:
> From: "Paul E. McKenney" <paul.mckenney@...aro.org>
> 
> When CONFIG_RCU_FAST_NO_HZ is enabled, RCU will allow a given CPU to
> enter dyntick-idle mode even if it still has RCU callbacks queued.
> RCU avoids system hangs in this case by scheduling a timer for several
> jiffies in the future.  However, if all of the callbacks on that CPU
> are from kfree_rcu(), there is no reason to wake the CPU up, as it is
> not a problem to defer freeing of memory.
> 
> This commit therefore tracks the number of callbacks on a given CPU
> that are from kfree_rcu(), and avoids scheduling the timer if all of
> a given CPU's callbacks are from kfree_rcu().

Minor nit: I think it would make much more sense to track the number of
"strict" callbacks *not* from kfree_rcu, and check for that number != 0,
rather than tracking the number of "lazy" callbacks from kfree_rcu and
checking for all != lazy.  You can always compute one number from the
other, but since you only ever need to know the strict count, not the
lazy count, why not directly track the thing you care about?

Also, any way this could hide the new kfree_call_rcu internally rather
than adding it as a new export?  In particular, why introduce a new
exported API only suitable for internal use or foot-shooting?

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