Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: Set hardirq tracing to on when idling
Date: Tue, 27 May 2014 21:39:22 +0200	[thread overview]
Message-ID: <10128642.DD2TJ8Ps9I@wuerfel> (raw)
In-Reply-To: <5384E892.90808@codeaurora.org>

On Tuesday 27 May 2014 12:33:38 Stephen Boyd wrote:
> On 05/27/14 12:27, Arnd Bergmann wrote:
> > On Tuesday 27 May 2014 11:53:59 Stephen Boyd wrote:
> >> On 05/27/14 11:49, Arnd Bergmann wrote:
> >>> You also commented in that thread about stop_critical_timings()/
> >>> start_critical_timings(). Corey, can you look at that, too? I
> >>> think it's designed to avoid the issue you are seeing but
> >>> for some reason doesn't.
> >> I sent a patch last week to "solve" this problem. I'm not sure if it's
> >> right but it works for me.
> >>
> >> https://lkml.org/lkml/2014/5/19/607
> > I think that one was also wrong, as the intention of the existing
> > stop_critical_timings() function is already to do the same that
> > Corey's patch does, i.e. stop the trace before we go to idle as
> > if we were turning IRQs on.
> 
> stop_critical_timings() is called in the generic idle loop. It looks
> like stop_critical_timings() just isn't written correctly. All it does
> is turn off the tracer, but it doesn't prevent future calls to
> spinlocks, etc. from causing the tracer to turn on again between calls
> to stop/start_critical_timings(). It seems better to prevent any more
> tracing from happening between a call to stop_critical_timings() and
> start_critical_timings() so we don't have to litter calls to that
> function throughout the idle path.

But are there any such calls in the idle function? I understand what
you are doing in your patch, but I don't see why you have to actually
do it.

	Arnd

  reply	other threads:[~2014-05-27 19:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-25 19:15 [PATCH] arm: Set hardirq tracing to on when idling minyard at acm.org
2014-05-26  9:26 ` Arnd Bergmann
2014-05-27 13:21   ` Corey Minyard
2014-05-27 16:16     ` Arnd Bergmann
2014-05-27 18:50       ` Corey Minyard
2014-05-27 16:38   ` Stanislav Meduna
2014-05-27 18:49     ` Arnd Bergmann
2014-05-27 18:53       ` Stephen Boyd
2014-05-27 19:27         ` Arnd Bergmann
2014-05-27 19:33           ` Stephen Boyd
2014-05-27 19:39             ` Arnd Bergmann [this message]
2014-05-27 20:22               ` Stephen Boyd
2014-05-28  0:28           ` Corey Minyard
2014-05-28  6:46             ` Arnd Bergmann

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=10128642.DD2TJ8Ps9I@wuerfel \
    --to=arnd@arndb.de \
    --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