Thread (1 message) 1 message, 1 author, 2012-02-03
DORMANTno replies

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

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

On Thu, Feb 02, 2012 at 06:53:50PM -0800, Josh Triplett wrote:
On Thu, Feb 02, 2012 at 09:45:31PM -0500, Steven Rostedt wrote:
quoted
On Thu, 2012-02-02 at 15:27 -0800, Paul E. McKenney wrote:
quoted
On Thu, Feb 02, 2012 at 06:03:39PM -0500, Steven Rostedt wrote:

[ . . . ]
quoted
Anyway, one answer is (and I was talking with Paul about this on IRC) is
that we can create a special "TRACE_EVENT_IDLE()" that will explicitly
call "rcu_idle_exit/enter()" as it expects to be called with it off.

This should solve most issues I believe.
You OK with something like RCU_NONIDLE() rather than RCU_EVENT_IDLE()?
I have this funny feeling that tracing won't be the only thing using
RCU from idle.  :-/

Something like this, perhaps?

	#define RCU_NONIDLE(a) \
		do { \
			rcu_idle_exit(); \
			do { a; } while (0); \
			rcu_idle_enter(); \
		}
I'm fine with this. But what is the overhead for doing such a thing.
Remember, to encapsulate a tracepoint means that you will be doing that
work everytime regardless if the tracepoint is ever activated or not. Or
even worse, not even compiled into the kernel.
Yeah, this should definitely try to avoid doing any work in the normal
case, if at all possible.  Not quite sure how to integrate that into
tracepoints, though, short of teaching the trace API how to deal with
getting invoked with RCU currently idle.
I agree that we need to apply this on a tracepoint-by-tracepoint basis --
too expensive for every tracepoint to be doing this, so reserve it for
the ones used in idle.

							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