[lkml]   [2009]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Question about usage of RCU in the input layer
On Fri, 20 Mar 2009 07:31:04 -0700
"Paul E. McKenney" <> 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?

(and I'm using 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
> and what value of HZ are you running?


> If each synchronize_rcu() is taking (say) tens of jiffies,
> then, as Peter Zijlstra notes earlier in this thread, we need to focus
> on what is taking too long to get through its RCU read-side
> critical sections

I know that "the other guy" is not optimal and takes waaay too long.

> Otherwise, if each synchronize_rcu() is
> in the 3-5 jiffy range, I may finally be forced to create an
> expedited version of the synchronize_rcu() API.

I think a simplified API for the "add to a list" case might make sense.
Because the request isn't for a full sync for sure...

(independent of that .. the open question is if this specific case is
even needed; I think the code confused "send to others" with "wait
until everyone sees"; afaik synchronize_rcu() has no pushing behavior
at all, nor should it)

> 2. If expediting is required, then the code calling
> synchronize_rcu() might or might not have any idea whether or not
> expediting is appropriate. If it does not, then we would need some
> sort of way to tell synchronize_rcu() that it should act more
> aggressively, perhaps /proc flag or kernel global variable indicating
> that boot is in progress.
> No, we do not want to make synchronize_rcu() aggressive all
> the time, as this would harm performance and energy efficiency in
> the normal runtime situation.
> So, if it turns out that synchronize_rcu()'s caller does not
> know whether or not expediting is appropriate, can the boot
> path manipulate such a flag or variable?
> 3. Which RCU implementation are you using? CONFIG_CLASSIC_RCU,


Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,

 \ /
  Last update: 2009-03-20 19:15    [W:0.091 / U:1.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site