All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: Byungchul Park <byungchul.park@lge.com>,
	linux-kernel@vger.kernel.org, Davidlohr Bueso <dave@stgolabs.net>,
	Josh Triplett <josh@joshtriplett.org>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	rcu@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>,
	kernel-team@android.com
Subject: Re: [PATCH] rcuperf: Make rcuperf kernel test more robust for !expedited mode
Date: Sat, 13 Jul 2019 07:18:50 -0700	[thread overview]
Message-ID: <20190713141850.GC26519@linux.ibm.com> (raw)
In-Reply-To: <20190705200003.GB134527@google.com>

On Fri, Jul 05, 2019 at 04:00:03PM -0400, Joel Fernandes wrote:
> On Fri, Jul 05, 2019 at 08:09:32AM -0700, Paul E. McKenney wrote:
> > On Fri, Jul 05, 2019 at 08:24:50AM -0400, Joel Fernandes wrote:
> > > On Fri, Jul 05, 2019 at 12:52:31PM +0900, Byungchul Park wrote:
> > > > On Thu, Jul 04, 2019 at 10:40:44AM -0700, Paul E. McKenney wrote:
> > > > > On Thu, Jul 04, 2019 at 12:34:30AM -0400, Joel Fernandes (Google) wrote:
> > > > > > It is possible that the rcuperf kernel test runs concurrently with init
> > > > > > starting up.  During this time, the system is running all grace periods
> > > > > > as expedited.  However, rcuperf can also be run for normal GP tests.
> > > > > > Right now, it depends on a holdoff time before starting the test to
> > > > > > ensure grace periods start later. This works fine with the default
> > > > > > holdoff time however it is not robust in situations where init takes
> > > > > > greater than the holdoff time to finish running. Or, as in my case:
> > > > > > 
> > > > > > I modified the rcuperf test locally to also run a thread that did
> > > > > > preempt disable/enable in a loop. This had the effect of slowing down
> > > > > > init. The end result was that the "batches:" counter in rcuperf was 0
> > > > > > causing a division by 0 error in the results. This counter was 0 because
> > > > > > only expedited GPs seem to happen, not normal ones which led to the
> > > > > > rcu_state.gp_seq counter remaining constant across grace periods which
> > > > > > unexpectedly happen to be expedited. The system was running expedited
> > > > > > RCU all the time because rcu_unexpedited_gp() would not have run yet
> > > > > > from init.  In other words, the test would concurrently with init
> > > > > > booting in expedited GP mode.
> > > > > > 
> > > > > > To fix this properly, let us check if system_state if SYSTEM_RUNNING
> > > > > > is set before starting the test. The system_state approximately aligns
> > > > 
> > > > Just minor typo..
> > > > 
> > > > To fix this properly, let us check if system_state if SYSTEM_RUNNING
> > > > is set before starting the test. ...
> > > > 
> > > > Should be
> > > > 
> > > > To fix this properly, let us check if system_state is set to
> > > > SYSTEM_RUNNING before starting the test. ...
> > > 
> > > That's a fair point. I wonder if Paul already fixed it up in his tree,
> > > however I am happy to resend if he hasn't. Paul, how would you like to handle
> > > this commit log nit?
> > > 
> > > it is just 'if ..' to 'is SYSTEM_RUNNING'
> > 
> > It now reads as follows:
> > 
> > 	To fix this properly, this commit waits until system_state is
> > 	set to SYSTEM_RUNNING before starting the test.  This change is
> > 	made just before kernel_init() invokes rcu_end_inkernel_boot(),
> > 	and this latter is what turns off boot-time expediting of RCU
> > 	grace periods.
> 
> Ok, looks good to me, thanks.
> 
> And for below patch,
> 
> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>

Applied, thank you!

							Thnax, Paul

> > I dropped the last paragraph about late_initcall().  And I suspect that
> > the last clause from rcu_gp_is_expedited() can be dropped:
> > 
> > bool rcu_gp_is_expedited(void)
> > {
> > 	return rcu_expedited || atomic_read(&rcu_expedited_nesting) ||
> > 	       rcu_scheduler_active == RCU_SCHEDULER_INIT;
> > }
> > 
> > This is because rcu_expedited_nesting is initialized to 1, and is
> > decremented in rcu_end_inkernel_boot(), which is called long after
> > rcu_scheduler_active has been set to RCU_SCHEDULER_RUNNING, which
> > happens at core_initcall() time.  So if the last clause says "true",
> > so does the second-to-last clause.
> > 
> > The similar check in rcu_gp_is_normal() is still need, however, to allow
> > the power-management subsystem to invoke synchronize_rcu() just after
> > the scheduler has been initialized, but before RCU is aware of this.
> > 
> > So, how about the commit shown below?
> > 
> > 							Thanx, Paul
> > 
> > ------------------------------------------------------------------------
> > 
> > commit 1f7e72efe3c761c2b34da7b59e01ad69c657db10
> > Author: Paul E. McKenney <paulmck@linux.ibm.com>
> > Date:   Fri Jul 5 08:05:10 2019 -0700
> > 
> >     rcu: Remove redundant "if" condition from rcu_gp_is_expedited()
> >     
> >     Because rcu_expedited_nesting is initialized to 1 and not decremented
> >     until just before init is spawned, rcu_expedited_nesting is guaranteed
> >     to be non-zero whenever rcu_scheduler_active == RCU_SCHEDULER_INIT.
> >     This commit therefore removes this redundant "if" equality test.
> >     
> >     Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
> > 
> > diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> > index 249517058b13..64e9cc8609e7 100644
> > --- a/kernel/rcu/update.c
> > +++ b/kernel/rcu/update.c
> > @@ -136,8 +136,7 @@ static atomic_t rcu_expedited_nesting = ATOMIC_INIT(1);
> >   */
> >  bool rcu_gp_is_expedited(void)
> >  {
> > -	return rcu_expedited || atomic_read(&rcu_expedited_nesting) ||
> > -	       rcu_scheduler_active == RCU_SCHEDULER_INIT;
> > +	return rcu_expedited || atomic_read(&rcu_expedited_nesting);
> >  }
> >  EXPORT_SYMBOL_GPL(rcu_gp_is_expedited);
> >  
> > 
> 

      reply	other threads:[~2019-07-13 14:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-04  4:34 [PATCH] rcuperf: Make rcuperf kernel test more robust for !expedited mode Joel Fernandes (Google)
2019-07-04 17:40 ` Paul E. McKenney
2019-07-05  3:52   ` Byungchul Park
2019-07-05 12:24     ` Joel Fernandes
2019-07-05 15:09       ` Paul E. McKenney
2019-07-05 20:00         ` Joel Fernandes
2019-07-13 14:18           ` Paul E. McKenney [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190713141850.GC26519@linux.ibm.com \
    --to=paulmck@linux.ibm.com \
    --cc=byungchul.park@lge.com \
    --cc=dave@stgolabs.net \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.