[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120615211902.GK2389@linux.vnet.ibm.com>
Date: Fri, 15 Jun 2012 14:19:02 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Josh Triplett <josh@...htriplett.org>
Cc: linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
dipankar@...ibm.com, akpm@...ux-foundation.org,
mathieu.desnoyers@...ymtl.ca, niv@...ibm.com, tglx@...utronix.de,
peterz@...radead.org, rostedt@...dmis.org, Valdis.Kletnieks@...edu,
dhowells@...hat.com, eric.dumazet@...il.com, darren@...art.com,
fweisbec@...il.com, patches@...aro.org,
"Paul E. McKenney" <paul.mckenney@...aro.org>
Subject: Re: [PATCH tip/core/rcu 6/6] rcu: Make rcutorture fakewriters invoke
rcu_barrier()
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@...aro.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@...aro.org>
> > Signed-off-by: Paul E. McKenney <paulmck@...ux.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
--
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/
Powered by blists - more mailing lists