linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, Corey Minyard <cminyard@mvista.com>,
	Stanislav Meduna <stano@meduna.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v2] tracing: Don't account for cpu idle time with irqsoff tracers
Date: Tue, 27 May 2014 17:25:57 -0700	[thread overview]
Message-ID: <20140528002557.GR22231@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140527193050.4606a014@gandalf.local.home>

On Tue, May 27, 2014 at 07:30:50PM -0400, Steven Rostedt wrote:
> On Tue, 27 May 2014 15:21:39 -0700
> Stephen Boyd <sboyd@codeaurora.org> wrote:
> 
> 
> > > Arnd brings up a good point. 
> > 
> > Hrm.. still not getting Arnd's mails.
> 
> Strange. What mail service do you have. Could they be blocking him?
> 
> > 
> > > If we disable irqs off tracing completely,
> > > we may be missing places in the idle path that disable interrupts for
> > > long periods of time. We may want to move the stop down further.
> > >
> > > The way it works (IIRC), and why tracing can start again is that it can
> > > nest. Perhaps we need to stop it further down if we can't move it
> > > completely.
> > >
> > 
> > I'm not sure how much deeper it can go and I'm afraid it will become a
> > game of whack-a-mole. I already see two places that disable and reenable
> > irqs after stop_critical_timings() is called (first in rcu_idle_enter()
> > and second in clockevents_notify()). Should rcu_idle_enter() move to
> > raw_local_irq_save()? It looks like that path calls rcu_sched_qs() and
> > on tiny RCU that again needs the raw_ treatement. We can probably call
> > stop_critical_timings() after rcu_idle_enter() to fix this.
> 
> I don't think we need to whack-a-mole. The start stop should be around
> where it goes to sleep.
> 
> > 
> > What about clockevents_notify? __raw_spin_lock_irqsave() should probably
> > use raw_local_irqsave().
> 
> No that solution is even worse. We need lockdep working here.
> 
> > 
> > If we go the raw route, do we even need stop/start_critical_timings()?
> > Can't we just use raw accessors in the idle paths
> > (tick_nohz_idle_{enter,exit}(), cpuidle_enter(), etc.) and get rid of
> > the stop/start stuff completely? I admit this patch is pretty much a big
> > sledge hammer that tries to make things simple, but if there is some
> > benefit to the raw accessors I'm willing to send patches to fix all the
> > call sites.
> > 
> 
> How about the following. I don't see any reason stop_critical_timings()
> can't be called from within rcu_idle code, as it doesn't use any rcu.
> 
> Paul, Peter, see anything wrong with this?

I don't immediately see any RCU use by stop_critical_timings(), but could
easily have missed something.  But CONFIG_PROVE_RCU=y will normally yell
if something using RCU showed up.

Looks plausible, but clearly needs testing across the usual array of
configs and arches.

							Thanx, Paul

> -- Steve
> 
> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> index 8f4390a..f5e6a64 100644
> --- a/kernel/sched/idle.c
> +++ b/kernel/sched/idle.c
> @@ -88,12 +88,6 @@ static int cpuidle_idle_call(void)
>  	}
> 
>  	/*
> -	 * During the idle period, stop measuring the disabled irqs
> -	 * critical sections latencies
> -	 */
> -	stop_critical_timings();
> -
> -	/*
>  	 * Tell the RCU framework we are entering an idle section,
>  	 * so no more rcu read side critical sections and one more
>  	 * step to the grace period
> @@ -144,6 +138,12 @@ static int cpuidle_idle_call(void)
>  				trace_cpu_idle_rcuidle(next_state, dev->cpu);
> 
>  				/*
> +				 * During the idle period, stop measuring the
> +				 * disabled irqs critical sections latencies
> +				 */
> +				stop_critical_timings();
> +
> +				/*
>  				 * Enter the idle state previously
>  				 * returned by the governor
>  				 * decision. This function will block
> @@ -154,6 +154,8 @@ static int cpuidle_idle_call(void)
>  				entered_state = cpuidle_enter(drv, dev,
>  							      next_state);
> 
> +				start_critical_timings();
> +
>  				trace_cpu_idle_rcuidle(PWR_EVENT_EXIT,
>  						       dev->cpu);
> 
> @@ -175,8 +177,11 @@ static int cpuidle_idle_call(void)
>  	 * We can't use the cpuidle framework, let's use the default
>  	 * idle routine
>  	 */
> -	if (ret)
> +	if (ret) {
> +		stop_critical_timings();
>  		arch_cpu_idle();
> +		start_critical_timings();
> +	}
> 
>  	__current_set_polling();
> 
> @@ -188,7 +193,6 @@ static int cpuidle_idle_call(void)
>  		local_irq_enable();
> 
>  	rcu_idle_exit();
> -	start_critical_timings();
> 
>  	return 0;
>  }
> 


  parent reply	other threads:[~2014-05-28  0:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-27 20:08 [PATCH v2] tracing: Don't account for cpu idle time with irqsoff tracers Stephen Boyd
2014-05-27 20:11 ` Arnd Bergmann
2014-05-27 21:48   ` Steven Rostedt
2014-05-27 22:21     ` Stephen Boyd
2014-05-27 23:30       ` Steven Rostedt
2014-05-28  0:11         ` Stephen Boyd
2014-05-28  0:23           ` Stephen Boyd
2014-05-28  0:42           ` Steven Rostedt
2014-05-28  7:24             ` Peter Zijlstra
2014-05-28 17:22               ` John Stultz
2014-05-28  0:25         ` Paul E. McKenney [this message]
2014-05-28  6:40         ` Arnd Bergmann
2014-05-28  6:44         ` Arnd Bergmann
2014-05-28  7:28         ` Peter Zijlstra
2014-05-28 14:09           ` Steven Rostedt

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=20140528002557.GR22231@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=arnd@arndb.de \
    --cc=cminyard@mvista.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sboyd@codeaurora.org \
    --cc=stano@meduna.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).