linux-kernel - Re: [PATCH RFC tip/core/rcu 17/41] rcu: Remove single-rcu_node optimization in rcu_start

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 18:13:14 -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
Subject: Re: [PATCH RFC tip/core/rcu 17/41] rcu: Remove single-rcu_node
 optimization in rcu_start_gp()

On Wed, Feb 01, 2012 at 11:41:35AM -0800, Paul E. McKenney wrote:
> The grace-period initialization sequence in rcu_start_gp() has a special
> case for systems where the rcu_node tree is a single rcu_node structure.
> This made sense some years ago when systems were smaller and up to 64
> CPUs could share a single rcu_node structure, but now that large systems
> are common and a given leaf rcu_node structure can support only 16 CPUs
> (due to lock contention on the rcu_node's ->lock field), this optimization
> is almost never taken.  And even the small mobile platforms that might
> make use of it might rather have the kernel text reduction.
> 
> Therefore, this commit removes the check for single-rcu_node trees.

This optimization would continue to work on laptops for a while longer.
:)

That said, I do agree that reducing code size and complexity seems
preferable.  If someone wants an optimization like this, they'd probably
do better to compile RCU with a low compile-time limit on the number of
CPUs, which would at least theoretically allow the compiler to get
similar results through optimization.  (I don't know if that works in
practice with the current code structure and the current intelligence of
GCC.)

Reviewed-by: Josh Triplett <josh@...htriplett.org>
--
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/