From: paulmck@linux.vnet.ibm.com (Paul E. McKenney)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC idle 2/3] arm: Avoid invoking RCU when CPU is idle
Date: Thu, 2 Feb 2012 22:04:58 -0800 [thread overview]
Message-ID: <20120203060458.GF2380@linux.vnet.ibm.com> (raw)
In-Reply-To: <1328237131.5882.135.camel@gandalf.stny.rr.com>
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.
>
> Now this is entering and exiting idle, so maybe it's not that critical?
It is an atomic instruction or two, plus some memory barriers. Entering
idle is more heavyweight for RCU_FAST_NO_HZ. But as you say, it is
entering and exiting idle.
But should I make an empty definition of RCU_NONIDLE() for some #define
or another?
#ifdef CONFIG_YOU_TELL_ME
#define RCU_NONIDLE(a) \
do { \
rcu_idle_exit(); \
do { a; } while (0); \
rcu_idle_enter(); \
} while (0)
#else /* #ifdef CONFIG_YOU_TELL_ME */
#define RCU_NONIDLE(a) do { } while (0);
#endif /* #else #ifdef CONFIG_YOU_TELL_ME */
Or is event tracing unconditional these days?
Thanx, Paul
next prev parent reply other threads:[~2012-02-03 6:04 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120202004253.GA10946@linux.vnet.ibm.com>
[not found] ` <1328143404-11038-1-git-send-email-paulmck@linux.vnet.ibm.com>
2012-02-02 0:43 ` [PATCH RFC idle 2/3] arm: Avoid invoking RCU when CPU is idle Paul E. McKenney
2012-02-02 2:48 ` Rob Herring
2012-02-02 4:40 ` Paul E. McKenney
2012-02-02 3:49 ` Nicolas Pitre
2012-02-02 4:44 ` Paul E. McKenney
2012-02-02 17:13 ` Nicolas Pitre
2012-02-02 17:43 ` Paul E. McKenney
2012-02-02 18:31 ` Nicolas Pitre
2012-02-02 19:07 ` Paul E. McKenney
2012-02-02 22:20 ` Kevin Hilman
2012-02-02 22:49 ` Rob Herring
2012-02-02 23:03 ` Steven Rostedt
2012-02-02 23:27 ` Paul E. McKenney
2012-02-02 23:51 ` Paul E. McKenney
2012-02-03 2:45 ` Steven Rostedt
2012-02-03 6:04 ` Paul E. McKenney [this message]
2012-02-03 18:55 ` Steven Rostedt
2012-02-03 19:40 ` Paul E. McKenney
2012-02-03 20:02 ` Steven Rostedt
2012-02-03 20:23 ` Paul E. McKenney
2012-02-06 21:18 ` [PATCH][RFC] tracing/rcu: Add trace_##name##__rcuidle() static tracepoint for inside rcu_idle_exit() sections Steven Rostedt
2012-02-06 23:38 ` Paul E. McKenney
2012-02-07 12:32 ` Steven Rostedt
2012-02-07 14:11 ` Paul E. McKenney
2012-02-08 13:57 ` Frederic Weisbecker
2012-02-07 14:40 ` Josh Triplett
[not found] ` <20120206220502.GA21340@leaf>
2012-02-07 0:36 ` Steven Rostedt
[not found] ` <20120203025350.GF13456@leaf>
2012-02-03 6:06 ` [PATCH RFC idle 2/3] arm: Avoid invoking RCU when CPU is idle Paul E. McKenney
2012-02-02 23:39 ` Rob Herring
2012-02-03 18:41 ` Kevin Hilman
2012-02-03 19:26 ` Paul E. McKenney
2012-02-03 19:36 ` Steven Rostedt
2012-02-04 14:21 ` Paul E. McKenney
2012-02-06 19:32 ` Steven Rostedt
2012-02-02 23:03 ` Paul E. McKenney
2012-02-03 19:12 ` Kevin Hilman
2012-02-03 19:26 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120203060458.GF2380@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).