All of lore.kernel.org
 help / color / mirror / Atom feed
From: Byungchul Park <byungchul.park@lge.com>
To: "Paul E. McKenney" <paulmck@linux.ibm.com>
Cc: "Joel Fernandes (Google)" <joel@joelfernandes.org>,
	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: Fri, 5 Jul 2019 12:52:31 +0900	[thread overview]
Message-ID: <20190705035231.GA31088@X58A-UD3R> (raw)
In-Reply-To: <20190704174044.GK26519@linux.ibm.com>

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

Thanks,
Byungchul

> > with when rcu_unexpedited_gp() is called and works well in practice.
> > 
> > I also tried late_initcall however it is still too early to be
> > meaningful for this case.
> > 
> > Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> 
> Good catch, queued, thank you!
> 
> 							Thanx, Paul
> 
> > ---
> >  kernel/rcu/rcuperf.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
> > index 4513807cd4c4..5a879d073c1c 100644
> > --- a/kernel/rcu/rcuperf.c
> > +++ b/kernel/rcu/rcuperf.c
> > @@ -375,6 +375,14 @@ rcu_perf_writer(void *arg)
> >  	if (holdoff)
> >  		schedule_timeout_uninterruptible(holdoff * HZ);
> >  
> > +	/*
> > +	 * Wait until rcu_end_inkernel_boot() is called for normal GP tests
> > +	 * so that RCU is not always expedited for normal GP tests.
> > +	 * The system_state test is approximate, but works well in practice.
> > +	 */
> > +	while (!gp_exp && system_state != SYSTEM_RUNNING)
> > +		schedule_timeout_uninterruptible(1);
> > +
> >  	t = ktime_get_mono_fast_ns();
> >  	if (atomic_inc_return(&n_rcu_perf_writer_started) >= nrealwriters) {
> >  		t_rcu_perf_writer_started = t;
> > -- 
> > 2.22.0.410.gd8fdbe21b5-goog
> > 

  reply	other threads:[~2019-07-05  3:53 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 [this message]
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

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=20190705035231.GA31088@X58A-UD3R \
    --to=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=paulmck@linux.ibm.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.