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

From: [email-masked] (Paul E. McKenney)
Date: Thu, 2 Feb 2012 22:06:58 -0800

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:
> > On Thu, 2012-02-02 at 15:27 -0800, Paul E. McKenney wrote:
> > > On Thu, Feb 02, 2012 at 06:03:39PM -0500, Steven Rostedt wrote:
> > > 
> > > [ . . . ]
> > > 
> > > > 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