From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753382AbbGAUqi (ORCPT ); Wed, 1 Jul 2015 16:46:38 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:54181 "EHLO e32.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752412AbbGAUqd (ORCPT ); Wed, 1 Jul 2015 16:46:33 -0400 X-Helo: d03dlp02.boulder.ibm.com X-MailFrom: paulmck@linux.vnet.ibm.com X-RcptTo: linux-kernel@vger.kernel.org Date: Wed, 1 Jul 2015 12:30:35 -0700 From: "Paul E. McKenney" To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, laijs@cn.fujitsu.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, josh@joshtriplett.org, tglx@linutronix.de, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, dvhart@linux.intel.com, fweisbec@gmail.com, oleg@redhat.com, bobby.prani@gmail.com Subject: Re: [PATCH RFC tip/core/rcu 5/5] rcu: Limit expedited helping to every 10 ms or every 4th GP Message-ID: <20150701193035.GO3717@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20150630214805.GA7795@linux.vnet.ibm.com> <1435700910-9104-1-git-send-email-paulmck@linux.vnet.ibm.com> <1435700910-9104-5-git-send-email-paulmck@linux.vnet.ibm.com> <20150701100730.GQ19282@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150701100730.GQ19282@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15070120-0005-0000-0000-0000133F8DCF Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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" > > 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 > > --- > > 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 > > >