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. 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) > > Thanx, Paul -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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
