From: khilman@ti•com (Kevin Hilman)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH RFC idle 2/3] arm: Avoid invoking RCU when CPU is idle
Date: Fri, 03 Feb 2012 11:12:49 -0800 [thread overview]
Message-ID: <87ty37689a.fsf@ti.com> (raw)
In-Reply-To: <20120202230326.GJ2518@linux.vnet.ibm.com> (Paul E. McKenney's message of "Thu, 2 Feb 2012 15:03:26 -0800")
"Paul E. McKenney" <paulmck@linux•vnet.ibm.com> writes:
> On Thu, Feb 02, 2012 at 02:20:26PM -0800, Kevin Hilman wrote:
>> "Paul E. McKenney" <paulmck@linux•vnet.ibm.com> writes:
>>
>> [...]
>>
>> >> > 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?
Yes, that should work.
And I defintely have examples of code paths that use tracepoints in both
idle and non-idle context (power domains, clocks, etc.) so the changes
to allow nesting will be needed.
Thanks,
Kevin
next prev parent reply other threads:[~2012-02-03 19:12 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
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 [this message]
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=87ty37689a.fsf@ti.com \
--to=khilman@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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