linux-kernel - Re: [PATCH RFC tip/core/rcu 5/5] rcu: Limit expedited helping to every 10 ms or every 4th GP

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]

Message-ID: <20150701193035.GO3717@linux.vnet.ibm.com>
Date:	Wed, 1 Jul 2015 12:30:35 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org, mingo@...nel.org,
	laijs@...fujitsu.com, dipankar@...ibm.com,
	akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
	josh@...htriplett.org, tglx@...utronix.de, rostedt@...dmis.org,
	dhowells@...hat.com, edumazet@...gle.com, dvhart@...ux.intel.com,
	fweisbec@...il.com, oleg@...hat.com, bobby.prani@...il.com
Subject: Re: [PATCH RFC tip/core/rcu 5/5] rcu: Limit expedited helping to
 every 10 ms or every 4th GP

On Wed, Jul 01, 2015 at 12:07:30PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 30, 2015 at 02:48:30PM -0700, Paul E. McKenney wrote:
> > From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
> 
> This seems like a good place to explain why this is a desirable thing,
> no?
> 
> Why would you want to limit this?

Good point!  I added the following to the commit log:

	Currently, the expedited grace period unconditionally awakens the
	normal grace period anytime there is a grace period in progress.
	However, this can be too much of a good thing for the following
	reasons: (1) It can result in excessive CPU consumption on
	the part of the RCU grace-period kthread, (2) The resulting
	variations in normal grace-period latency may cause confusion
	(as Josh Triplett points out), and (3) In many cases, reducing
	normal grace-period latency will be of little or no value.
	This commit therefore does the wakeups only once per ten jiffies
	or every fourth grace period, whichever is more frequent.

Does that help?

							Thanx, Paul

> > Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> > ---
> >  kernel/rcu/tree.c | 15 ++++++++++++---
> >  1 file changed, 12 insertions(+), 3 deletions(-)
> > 
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index 308b6acb4260..247aa1120c4c 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -3505,10 +3505,19 @@ void synchronize_sched_expedited(void)
> >  			   !atomic_read(&rsp->expedited_need_qs));
> >  
> >  	rcu_exp_gp_seq_end(rsp);
> > -	mutex_unlock(&rnp->exp_funnel_mutex);
> >  	smp_mb(); /* ensure subsequent action seen after grace period. */
> > -	if (rsp->gp_kthread && rcu_gp_in_progress(rsp))
> > -		wake_up(&rsp->gp_wq);
> > +	if (rsp->gp_kthread && rcu_gp_in_progress(rsp)) {
> > +		static unsigned long nextgp;
> > +		static unsigned long nextjiffy;
> > +
> > +		if (time_after_eq(jiffies, nextgp) ||
> > +		    ULONG_CMP_GE(rsp->gpnum, nextgp)) {
> > +			nextgp = rsp->gpnum + 4;
> > +			nextjiffy = jiffies + 10;
> > +			wake_up(&rsp->gp_wq);
> > +		}
> > +	}
> > +	mutex_unlock(&rnp->exp_funnel_mutex);
> >  
> >  	put_online_cpus();
> >  }
> > -- 
> > 1.8.1.5
> > 
> 

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