[PATCH RFC idle 2/3] arm: Avoid invoking RCU when CPU is idle
Paul E. McKenney
paulmck at linux.vnet.ibm.com
Fri Feb 3 01:06:58 EST 2012
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
More information about the linux-arm-kernel
mailing list