Thread (19 messages) flat view 19 messages, 6 authors, 2012-02-08
STALE5290d

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

From: Paul E. McKenney <hidden>
Date: 2012-02-02 23:03:26
Also in: linux-omap, linux-samsung-soc

On Thu, Feb 02, 2012 at 02:20:26PM -0800, Kevin Hilman wrote:
"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.
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?

							Thanx, Paul
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help