[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 11:12:49AM -0800, Kevin Hilman wrote:
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes:
> 
> > On Thu, Feb 02, 2012 at 02:20:26PM -0800, 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.
> >
> > OK...
> >
> > What if the tracing code between the rcu_idle_enter() and the
> > rcu_idle_exit() had to be enclosed in a wrapper?  For example,
> > the tracing in cpuidle_idle_call() might appear as follows:
> >
> > 	RCU_NONIDLE(
> > 		trace_power_start(POWER_CSTATE, next_state, dev->cpu);
> > 		trace_cpu_idle(next_state, dev->cpu);
> > 	);
> >
> > 	entered_state = target_state->enter(dev, drv, next_state);
> >
> > 	RCU_NONIDLE(
> > 		trace_power_end(dev->cpu);
> > 		trace_cpu_idle(PWR_EVENT_EXIT, dev->cpu);
> > 	);
> >
> > The RCU_NONIDLE() macro would do rcu_idle_exit(), execute its
> > argument, then do rcu_idle_enter().  (Credit to Steven Rostedt
> > for suggesting this.)  Given the possibility of code invoked both
> > from idle and not-idle, I have some changes to rcu to allow nesting
> > of rcu_idle_enter() and rcu_idle_exit().
> >
> > Would that work for you?
> 
> Yes, that should work.
> 
> And I defintely have examples of code paths that use tracepoints in both
> idle and non-idle context (power domains, clocks, etc.) so the changes
> to allow nesting will be needed.

OK, good to know that my paranoia is still functioning correctly.  ;-)

							Thanx, Paul