lkml.org 
[lkml]   [2009]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Question about usage of RCU in the input layer
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@linux.vnet.ibm.com> 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@linux.vnet.ibm.com> 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.

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

\
 
 \ /
  Last update: 2009-03-21 22:11    [W:0.071 / U:8.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site