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-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
