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

On Fri, Feb 03, 2012 at 10:41:01AM -0800, Kevin Hilman wrote:

Rob Herring [off-list ref] writes:

quoted

On 02/02/2012 04:20 PM, Kevin Hilman wrote:

quoted

"Paul E. McKenney" [off-list ref] writes:

[...]

quoted

quoted

quoted

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

quoted

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.)

quoted

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.

quoted

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