From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Josh Triplett <josh@joshtriplett.org>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
laijs@cn.fujitsu.com, dipankar@in.ibm.com,
akpm@linux-foundation.org, mathieu.desnoyers@polymtl.ca,
niv@us.ibm.com, tglx@linutronix.de, peterz@infradead.org,
rostedt@goodmis.org, Valdis.Kletnieks@vt.edu,
dhowells@redhat.com, eric.dumazet@gmail.com, darren@dvhart.com,
fweisbec@gmail.com, patches@linaro.org,
"Paul E. McKenney" <paul.mckenney@linaro.org>
Subject: Re: [PATCH tip/core/rcu 6/6] rcu: Make rcutorture fakewriters invoke rcu_barrier()
Date: Fri, 15 Jun 2012 14:19:02 -0700 [thread overview]
Message-ID: <20120615211902.GK2389@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120615203705.GE31184@leaf>
On Fri, Jun 15, 2012 at 01:37:05PM -0700, Josh Triplett wrote:
> On Fri, Jun 15, 2012 at 11:57:54AM -0700, Paul E. McKenney wrote:
> > From: "Paul E. McKenney" <paul.mckenney@linaro.org>
> >
> > The current rcutorture rcu_barrier() testing never intentionally runs
> > more than one instance of rcu_barrier() at a given time. This fails
> > to test the the shiny new concurrency features of rcu_barrier(). This
> > commit therefore modifies the rcutorture fakewriter kthread to randomly
> > invoke rcu_barrier() rather than the usual synchronize_rcu().
> >
> > Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > ---
> > kernel/rcutorture.c | 6 +++++-
> > 1 files changed, 5 insertions(+), 1 deletions(-)
> >
> > diff --git a/kernel/rcutorture.c b/kernel/rcutorture.c
> > index 54a3745..dfb4e20 100644
> > --- a/kernel/rcutorture.c
> > +++ b/kernel/rcutorture.c
> > @@ -1025,7 +1025,11 @@ rcu_torture_fakewriter(void *arg)
> > do {
> > schedule_timeout_uninterruptible(1 + rcu_random(&rand)%10);
> > udelay(rcu_random(&rand) & 0x3ff);
> > - cur_ops->sync();
> > + if (cur_ops->cb_barrier != NULL &&
> > + rcu_random(&rand) % (NR_CPUS * 8) == 0)
>
> NR_CPUS seems like an odd choice here. I assume you want to control for
> having many rcu_torture_fakewriter threads, and aim for the same average
> rate of barrier calls across the whole set of threads regardless of the
> number of threads. However, NR_CPUS does not accurately reflect either
> the number of fakewriter threads (which a user can set arbitrarily) or
> the number of CPUs currently on the system (since NR_CPUS represents the
> compile-time limit). I'd suggest changing this to use the actual number
> of fakewriter threads, which rcutorture knows at start time.
Indeed, this should use the number of online CPUs. Which should be
easy to compute, will fix.
Also will fix the commit message as suggested, and apply your reviewed-bys
as specified.
Thanx, Paul
next prev parent reply other threads:[~2012-06-15 21:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-15 18:57 [PATCH tip/core/rcu 0/6] rcutorture and documentation patches for 3.6 Paul E. McKenney
2012-06-15 18:57 ` [PATCH tip/core/rcu 1/6] rcu: Update documentation to cover call_srcu() and srcu_barrier() Paul E. McKenney
2012-06-15 18:57 ` [PATCH tip/core/rcu 2/6] rcu: Rationalize ordering of torture_ops list Paul E. McKenney
2012-06-15 20:21 ` Josh Triplett
2012-06-15 18:57 ` [PATCH tip/core/rcu 3/6] rcu: Test srcu_barrier() from rcutorture test suite Paul E. McKenney
2012-06-15 20:25 ` Josh Triplett
2012-06-15 18:57 ` [PATCH tip/core/rcu 4/6] rcu: Fix bug in rcu_barrier() torture test Paul E. McKenney
2012-06-15 19:44 ` Mathieu Desnoyers
2012-06-15 20:16 ` Paul E. McKenney
2012-06-15 18:57 ` [PATCH tip/core/rcu 5/6] rcu: Fix diagnostic-printk typo in rcutorture Paul E. McKenney
2012-06-15 20:30 ` Josh Triplett
2012-06-15 18:57 ` [PATCH tip/core/rcu 6/6] rcu: Make rcutorture fakewriters invoke rcu_barrier() Paul E. McKenney
2012-06-15 20:37 ` Josh Triplett
2012-06-15 21:19 ` Paul E. McKenney [this message]
2012-06-15 21:52 ` Josh Triplett
2012-06-15 23:48 ` Paul E. McKenney
2012-06-15 20:19 ` [PATCH tip/core/rcu 1/6] rcu: Update documentation to cover call_srcu() and srcu_barrier() Josh Triplett
2012-06-15 21:16 ` 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=20120615211902.GK2389@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=darren@dvhart.com \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=eric.dumazet@gmail.com \
--cc=fweisbec@gmail.com \
--cc=josh@joshtriplett.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@elte.hu \
--cc=niv@us.ibm.com \
--cc=patches@linaro.org \
--cc=paul.mckenney@linaro.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox