public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Don Zickus <dzickus@redhat.com>
Cc: mingo@elte.hu, peterz@infradead.org, gorcunov@gmail.com,
	aris@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [watchdog] combine nmi_watchdog and softlockup
Date: Fri, 9 Apr 2010 02:22:45 +0200	[thread overview]
Message-ID: <20100409002243.GD6672@nowhere> (raw)
In-Reply-To: <20100406185938.GT15159@redhat.com>

On Tue, Apr 06, 2010 at 02:59:38PM -0400, Don Zickus wrote:
> > I fear the cpu clock is not going to help you detecting any hard lockups.
> > If you're stuck in an interrupt or an irq disabled loop, your cpu clock is
> > not going to fire.
> 
> Yup.  I put that in the changelog of some nmi code I posted a few weeks
> ago.  I believe Ingo was looking to have a fallback plan in case hw perf
> events wasn't available.


I'm not sure a fallback plan is welcome. What we want is a single
implementation.
If archs already have their own hardlockup detectors, then good
for them as they have this fallback implementation already.

For those who haven't it or who want to profit from a generic
code that does a good deal of the error prone work for them already,
they can just implement a basic perf support for the cpu-cycle
events.

Perf events gives a chance to provide a generic support for hardlockup
detection and supporting a fallback solution from generic code would
be a waste of time.

 
> With this code, moving to sw perf events, kinda kills the ability to
> detect hard lockups, but you can still detect softlockups.


Totally. Actually the hardlockup part should be even ifdef'ed.
What is not nice is that we have a dependency to CONFIG_PERF_EVENT
for the softlockup detector now while that could be avoided easily.

You have the following layer:

- A task that updates softlockup last touch
- An hrtimer that wakes up this task and logs the irq progression
- A (in the best case) NMI that checks the irq progression and the softlockup
  last touch progression.

Why not moving the softlockup last touch progression check from the hrtimer too?
This way you avoid the perf events dependency for the softlockup detector.
The new layer can then be:

- The task
- hrtimer: check softlockup last touch progression (is_softlockup()) and
  then wake up the task again. Log irq progression.
- NMI: check irq progression.

This way can just ifdef all the perf events related things, only useful
for the hardlockup detector. And the softlockup detector can still be used
by archs that don't have perf events support.


      reply	other threads:[~2010-04-09  0:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-23 21:33 [watchdog] combine nmi_watchdog and softlockup Don Zickus
2010-03-28  2:46 ` Aristeu Sergio Rozanski Filho
2010-03-29 18:26   ` Don Zickus
2010-03-30 14:52     ` Aristeu Sergio Rozanski Filho
2010-04-05 20:11       ` Cyrill Gorcunov
2010-04-05 20:16         ` Don Zickus
2010-04-05 14:11 ` Don Zickus
2010-04-09  1:02   ` Frederic Weisbecker
2010-04-09 13:32     ` Don Zickus
2010-04-06 14:13 ` Frederic Weisbecker
2010-04-06 15:31   ` Cyrill Gorcunov
2010-04-08 23:52     ` Frederic Weisbecker
2010-04-09  0:00     ` Frederic Weisbecker
2010-04-09 14:56       ` Cyrill Gorcunov
2010-04-09 15:05         ` Don Zickus
2010-04-06 18:59   ` Don Zickus
2010-04-09  0:22     ` Frederic Weisbecker [this message]

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=20100409002243.GD6672@nowhere \
    --to=fweisbec@gmail.com \
    --cc=aris@redhat.com \
    --cc=dzickus@redhat.com \
    --cc=gorcunov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@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