Re: Question about usage of RCU in the input layer

[Paul E. McKenney]

On Sat, Mar 21, 2009 at 08:40:45PM -0700, Arjan van de Ven wrote:
> On Sat, 21 Mar 2009 14:07:45 -0700
> "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
> 
> > On Sat, Mar 21, 2009 at 09:26:08PM +0100, Eric Dumazet wrote:
> > > Arjan van de Ven a écrit :
> > > > On Fri, 20 Mar 2009 18:27:46 -0700
> > > > "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
> > > > 
> > > >> On Fri, Mar 20, 2009 at 11:13:54AM -0700, Arjan van de Ven wrote:
> > > >>> On Fri, 20 Mar 2009 07:31:04 -0700
> > > >>> "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
> > > >>>>> that'd be throwing out the baby with the bathwater... I'm
> > > >>>>> trying to use the other cpus to do some of the boot work (so
> > > >>>>> that the total goes faster); not using the other cpus would be
> > > >>>>> counter productive to that. (As is just sitting in
> > > >>>>> synchronize_rcu() when the other cpu is working.. hence this
> > > >>>>> discussion ;-)
> > > >>>> OK, so you are definitely running multiple CPUs when the
> > > >>>> offending synchronize_rcu() executes, then?
> > > >>> absolutely. 
> > > >>> (and I'm using bootgraph.pl in scripts to track who's stalling
> > > >>> etc)
> > > >>>> If so, here are some follow-on questions:
> > > >>>>
> > > >>>> 1.	How many synchronize_rcu() calls are you seeing on
> > > >>>> the critical boot path
> > > >>> I've seen only this (input) one to take a long time
> > > >> Ouch!!!  A -single- synchronize_rcu() taking a full second???
> > > >> That indicates breakage.
> > > >>
> > > >>>>  and what value of HZ are you running?
> > > >>> 1000
> > > >> K, in absence of readers for RCU_CLASSIC, we should see a handful
> > > >> of milliseconds for synchronize_rcu().
> > > > 
> > > > I've attached an instrumented bootgraph of what is going on;
> > > > the rcu delays are shown as red blocks inside the regular
> > > > functions as they initialize......
> > > > 
> > > > (svg can be viewed with inkscape, gimp, firefox and various other
> > > > tools)
> > > 
> > > Interesting stuff...
> > > 
> > > I thought you mentioned i2c drivers being source of the udelays(),
> > >  but I cant see them in this svg, unless its async_probe_hard ?
> > 
> > Arjan, another thought -- if the udelays() are not under
> > rcu_read_lock(), you should be able to finesse this by using
> > CONFIG_PREEMPT_RCU, which will happily ignore spinning CPUs as long
> > as they are not in an RCU read-side critical section.
> 
> I'll play with that
> In the mean time I've reduced the "other" function's time significantly;
> so the urgency has gone away some.

Good to hear!

> It's still "interesting" that even in the "there is only really one
> thread running" case the minimum delay seems to be 2700 microseconds
> for classic RCU. Especially during bootup that sounds a bit harsh....
> (since that is where many "read mostly" cases actually get their
> modifications)

OK, I'll bite...  2700 microseconds measures exactly what?

Also, "really one thread" means hardware threads or software threads?
If the former, exactly which kernel are you using?  The single-CPU
optimization was added in 2.6.29-rc7, commit ID a682604838.

							Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/