linux-kernel - Re: [PATCH tip/core/rcu 6/7] rcu: Drive quiescent-state-forcing delay from HZ

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:	Tue, 28 May 2013 18:29:26 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Josh Triplett <josh@...htriplett.org>,
	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,
	rostedt@...dmis.org, Valdis.Kletnieks@...edu, dhowells@...hat.com,
	edumazet@...gle.com, darren@...art.com, fweisbec@...il.com,
	sbw@....edu
Subject: Re: [PATCH tip/core/rcu 6/7] rcu: Drive quiescent-state-forcing
 delay from HZ

On Tue, May 28, 2013 at 12:07:42PM +0200, Ingo Molnar wrote:
> 
> * Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:
> 
> > On Wed, May 15, 2013 at 11:20:55AM +0200, Ingo Molnar wrote:
> > > 
> > > * Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:
> > > 
> > > > rcu: Fix comparison sense in rcu_needs_cpu()
> > > > 
> > > > Commit c0f4dfd4f (rcu: Make RCU_FAST_NO_HZ take advantage of numbered
> > > > callbacks) introduced a bug that can result in excessively long grace
> > > > periods.  This bug reverse the senes of the "if" statement checking
> > > > for lazy callbacks, so that RCU takes a lazy approach when there are
> > > > in fact non-lazy callbacks.  This can result in excessive boot, suspend,
> > > > and resume times.
> > > > 
> > > > This commit therefore fixes the sense of this "if" statement.
> > > > 
> > > > Reported-by: Borislav Petkov <bp@...en8.de>
> > > > Reported-by: Bj?rn Mork <bjorn@...k.no>
> > > > Reported-by: Joerg Roedel <joro@...tes.org>
> > > > Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> > > > 
> > > > diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
> > > > index 170814d..6d939a6 100644
> > > > --- a/kernel/rcutree_plugin.h
> > > > +++ b/kernel/rcutree_plugin.h
> > > > @@ -1667,7 +1667,7 @@ int rcu_needs_cpu(int cpu, unsigned long *dj)
> > > >  	rdtp->last_accelerate = jiffies;
> > > >  
> > > >  	/* Request timer delay depending on laziness, and round. */
> > > > -	if (rdtp->all_lazy) {
> > > > +	if (!rdtp->all_lazy) {
> > > >  		*dj = round_up(rcu_idle_gp_delay + jiffies,
> > > >  			       rcu_idle_gp_delay) - jiffies;
> > > 
> > > Neat - could this explain sporadic long (but not infinite) boot times with 
> > > NOHZ_FULL?
> > > 
> > > We changed HZ to be at least 1 Hz pretty recently, which might have worked 
> > > around this bug.
> > 
> > Quite possibly...
> > 
> > Of course, I don't see the boot slowdowns in my testing.  :-/
> 
> They were pretty sporadic and only popped up (and down) during randconfig 
> testing. Simple unrelated changes to the .config made them go away - 
> heisenbugs.

I can believe that...  The system has to be very quiet for this bug to
significantly slow down boot.  Interrupts scattered across CPUs (for
example) would tend to force RCU's state machine forward.

							Thanx, Paul

> Thanks,
> 
> 	Ingo
> 

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