[PATCH RFC idle 2/3] arm: Avoid invoking RCU when CPU is idle

[paulmck@linux.vnet.ibm.com (Paul E. McKenney)]

On Fri, Feb 03, 2012 at 10:41:01AM -0800, Kevin Hilman wrote:
> Rob Herring <robherring2@gmail.com> writes:
> 
> > On 02/02/2012 04:20 PM, Kevin Hilman wrote:
> >> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes:
> >> 
> >> [...]
> >> 
> >>>>> The two options I see are:
> >>>>>
> >>>>> 1.	Rip tracing out of the inner idle loops and everything that
> >>>>> 	they invoke.
> >>>>
> >>>> What I suggested above.  But as I said I know sh*t about that tracing 
> >>>> implementation so that's an easy suggestion for me to make.
> >>>
> >>> Works for me as well.  ;-)
> >> 
> >> While I must admit not having a better suggestion, I for one would vote
> >> strongly against removing tracing from the idle path.
> >> 
> >> Being a PM developer and maintainer, much of the code I work on and
> >> maintain happens to be run in the bowels of the idle path.  Not having
> >> the ability to trace this code would be a major step backwards IMO.
> >
> > How is it a step backwards if it is already broken. 
> 
> Well, I didn't know it was broken. ;) And, as Paul mentioned, this has
> been broken for a long time. Apparently it's been working well enough
> for nobody to notice until recently.

Yep.  The probability is quite low, but the consequences are dire.
We might well have hit it occasionally -- it would be a random
inexplicable crash.

							Thanx, Paul

> > Obviously you haven't actually used any tracing here because it
> > doesn't work right with things as is.
> 
> It's been working well enough for me to debug several idle path problems
> with tracing.  Admittedly, this has been primarily on UP systems, but
> I've recently started using the tracing on SMP as well.  (however, due
> to "coupled" low-power states on OMAP, large parts of the idle path are
> effectively UP since one CPU0 has to wait for CPU1 to hit a low-power
> state before it can.)
> 
> > What exactly do you want to trace at this level. By the point you are in
> > this code, the path is somewhat known and problems you have are likely
> > h/w issues. 
> 
> Not really. 
> 
> There is still quite a bit of software between the decision to enter
> idle and the hardware taking over.  On OMAP for example, we have power
> domains, clock domains and clocks that are managed during idle, and
> these layers contain tracepoints.
> 
> Add to that the runtime PM management of some devices that are coupled
> to the CPU (because they share a power domain, etc).  Runtime PM
> contains tracepoints.
> 
> Add to that possible voltage scaling during idle using regulators.
> Regulator framework has tracepoints.
> 
> That can lead to quite a bit of tracing info *after* the decision to
> enter idle.
> 
> > If you are trying to go thru a very precise sequence of
> > saving cpu state and flushing caches, you don't want calls out to
> > tracing code that could very easily change the behavior.
> 
> I'm more worried about the power domain and voltage domain transitions
> (or lack thereof) when trying to debug why a particular low-power state
> was not hit.
> 
> Kevin
>