All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: linux-arm-kernel@lists.infradead.org,
	Corey Minyard <cminyard@mvista.com>,
	linux-rt-users@vger.kernel.org, minyard@acm.org,
	linux-kernel@vger.kernel.org, Stanislav Meduna <stano@meduna.org>
Subject: Re: [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

WARNING: multiple messages have this Message-ID (diff)
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: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-25 19:15 [PATCH] arm: Set hardirq tracing to on when idling minyard
2014-05-25 19:15 ` minyard at acm.org
2014-05-26  9:26 ` Arnd Bergmann
2014-05-26  9:26   ` Arnd Bergmann
2014-05-27 13:21   ` Corey Minyard
2014-05-27 13:21     ` Corey Minyard
2014-05-27 16:16     ` Arnd Bergmann
2014-05-27 16:16       ` Arnd Bergmann
2014-05-27 18:50       ` Corey Minyard
2014-05-27 18:50         ` Corey Minyard
2014-05-27 16:38   ` Stanislav Meduna
2014-05-27 16:38     ` Stanislav Meduna
2014-05-27 18:49     ` Arnd Bergmann
2014-05-27 18:49       ` Arnd Bergmann
2014-05-27 18:53       ` Stephen Boyd
2014-05-27 18:53         ` Stephen Boyd
2014-05-27 19:27         ` Arnd Bergmann
2014-05-27 19:27           ` Arnd Bergmann
2014-05-27 19:33           ` Stephen Boyd
2014-05-27 19:33             ` Stephen Boyd
2014-05-27 19:39             ` Arnd Bergmann [this message]
2014-05-27 19:39               ` Arnd Bergmann
2014-05-27 20:22               ` Stephen Boyd
2014-05-27 20:22                 ` Stephen Boyd
2014-05-28  0:28           ` Corey Minyard
2014-05-28  0:28             ` Corey Minyard
2014-05-28  6:46             ` Arnd Bergmann
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=cminyard@mvista.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=minyard@acm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.