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 ? -- 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
