linux-kernel - Re: [PATCH tip/core/rcu 02/11] rcu: Expedite during suspend and resume only on smallish systems

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:	Sun, 18 Aug 2013 17:32:43 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Josh Triplett <josh@...htriplett.org>
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, dhowells@...hat.com,
	edumazet@...gle.com, darren@...art.com, fweisbec@...il.com,
	sbw@....edu
Subject: Re: [PATCH tip/core/rcu 02/11] rcu: Expedite during suspend and
 resume only on smallish systems

On Sat, Aug 17, 2013 at 08:18:32PM -0700, Josh Triplett wrote:
> On Sat, Aug 17, 2013 at 06:37:47PM -0700, Paul E. McKenney wrote:
> > From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
> > 
> > Expedited grace periods are of dubious benefit on very large systems,
> > so this commit restricts their automated use during suspend and resume
> > to systems of 256 or fewer CPUs.
> > 
> > Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> 
> This seems odd.  If expedited grace periods don't help on large systems,
> shouldn't you just compile them out entirely and ignore rcu_expedited,
> rather than just in this one special case?

Longer term, a bunch of stuff will need optimization for larger systems.
Expedited RCU grace periods, rcu_barrier(), possibly even grace-period
initialization and cleanup.  Also smp_call_function(), along with other
primitives that have broadcast semantics.  These changes would allow
this hack to be removed.

The most straightforward approach would be to provision helper kthreads,
increasing the number of helper kthreads with the number of CPUs.  But
I would like to see actual problems due to the lack of scalability before
adding more complexity to RCU.  ;-)

> In any case, if this patch still makes sense, please squash it into the
> previous one.

Fair enough, done!

							Thanx, Paul

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