All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Zickus <dzickus@redhat.com>
To: Stephane Eranian <eranian@google.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"Pan, Zhenjie" <zhenjie.pan@intel.com>,
	"paulus@samba.org" <paulus@samba.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"acme@ghostprotocols.net" <acme@ghostprotocols.net>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"Liu, Chuansheng" <chuansheng.liu@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] NMI: fix NMI period is not correct when cpu frequency changes issue.
Date: Thu, 18 Apr 2013 09:39:27 -0400	[thread overview]
Message-ID: <20130418133927.GJ79013@redhat.com> (raw)
In-Reply-To: <CABPqkBTpzSBEezx4ScwYYX6L8ir4GLBG9MMYJuAb6YA0QbiurQ@mail.gmail.com>

On Thu, Apr 18, 2013 at 02:04:00PM +0200, Stephane Eranian wrote:
> On Thu, Apr 18, 2013 at 1:42 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > On Tue, 2013-04-16 at 06:57 +0000, Pan, Zhenjie wrote:
> >> Watchdog use performance monitor of cpu clock cycle to generate NMI to detect hard lockup.
> >> But when cpu's frequency changes, the event period will also change.
> >> It's not as expected as the configration.
> >> For example, set the NMI event handler period is 10 seconds when the cpu is 2.0GHz.
> >> If the cpu changes to 800MHz, the period will be 10*(2000/800)=25 seconds.
> >> So it may make hard lockup detect not work if the watchdog timeout is not long enough.
> >> Now, set a notifier to listen to the cpu frequency change.
> >> And dynamic re-config the NMI event to make the event period correct.
> >>
> >
> >
> > Urgh,. does this really matter.. all we really want is for that NMI to
> > hit eventually in the not too distant future. Does the frequency really
> > matter _that_ much?
> >
> I agree, it does not really matter. Set the watchdog to a couple of minutes
> and it should be fine, shouldn't it?

I believe it mattered to the Chrome folks. They want the watchdog to be as
tight as possible so the user experience isn't a hang but a quick reboot
instead.  They like setting the watchdog to something like 2 seconds.

There was a patch a few months ago that tried to hack around this issue
and I suggested this approach as a better solution.  I forgot what the
original problem was.  Perhaps someone can jump in and explain the problem
being solved (other than the watchdog isn't always 10 seconds)?

Cheers,
Don

> 
> > Also, can't we simply pick an event that's invariant to the cpufreq
> > nonsense? Something like CPU_CLK_UNHALTED.REF -- or better the
> > fixed_ctr2 which nobody ever uses anyway.
> >
> You don't want to use fixed counter 2 for NMI watchdog because it's pinned.
> No other counter can count this event. And it is very useful. I use it often.

  reply	other threads:[~2013-04-18 13:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-16  6:57 [PATCH v2] NMI: fix NMI period is not correct when cpu frequency changes issue Pan, Zhenjie
2013-04-18 11:42 ` Peter Zijlstra
2013-04-18 12:04   ` Stephane Eranian
2013-04-18 13:39     ` Don Zickus [this message]
2013-04-22  0:50       ` Pan, Zhenjie
2013-04-22 18:59         ` Don Zickus
2013-04-23  0:52           ` Pan, Zhenjie
2013-04-22 20:37         ` Peter Zijlstra
2013-04-23 18:14           ` Don Zickus

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=20130418133927.GJ79013@redhat.com \
    --to=dzickus@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@ghostprotocols.net \
    --cc=akpm@linux-foundation.org \
    --cc=chuansheng.liu@intel.com \
    --cc=eranian@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    --cc=tglx@linutronix.de \
    --cc=zhenjie.pan@intel.com \
    /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.