From: Thomas Gleixner <tglx@linutronix.de>
To: Joel Fernandes <agnel.joel@gmail.com>
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Frédéric Weisbecker" <fweisbec@gmail.com>
Subject: Re: High rate of touch_softlockup makes Soft Lockup detector useless
Date: Thu, 7 Jul 2016 17:17:24 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.11.1607071653440.4083@nanos> (raw)
In-Reply-To: <CAD=GYpZf=UOkV0UEk-xeqTfZzHfyHfh+ecPkOrC_6YmA8_eBAw@mail.gmail.com>
On Wed, 6 Jul 2016, Joel Fernandes wrote:
> In a system running a recent kernel, I am trying to use soft lockup
> detector to detect soft lockups in the system.
> During this exercise, I see that even with real soft lockups, the
> kernel is unable to detect them.
What is your definition of a real soft lockup?
> Digging in further, I found that the softlockup watchdog is touched
> 1000s of times per second by the NOHZ code.
> prints revealed the following 2 functions calling touch_softlockup_watchdog:
> [ 165.960292] CPU0 touch: tick_nohz_restart_sched_tick
> [ 165.960309] CPU1 touch: tick_nohz_update_jiffies
>
> I am wondering, do we really need to touch the softlockup watchdog
> from the tick_nohz code?
> From the code comments it looks like the watchdog is touch'ed because
> the tick was off and was being turned on so it could the watchdog may
> not have been touched for a long time.
> BUT, wouldn't the hrtimer interrupt for the watchdog timer cause the
> watchdog thread to be scheduled even though the tick was off for a
> long time? Then in that case do we really need to touch the softlockup
> watchdog from the tick_nohz code?
Yes, it will be scheduled, but it might be too late. Assume the following:
t1 hrtimer fires
watchdog thread runs
watchdog timer is rearmed to t2 = t1 + period
idle sleep
t2 - 1ms long running thread gets scheduled
t2 hrtimer fires
long running thread stops
watchdog thread runs and detects soft lockup
The soft lockup detector checks whether the CPU is hogged by some random
task. It does so by monitoring whether the watchdog task which is peridocially
scheduled by a hrtimer becomes running before the watchdog period elapses.
If the cpu goes idle then nothing hogs the cpu and the check period can be
canceled.
Thanks,
tglx
next prev parent reply other threads:[~2016-07-07 15:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-07 5:05 Joel Fernandes
2016-07-07 15:17 ` Thomas Gleixner [this message]
2016-07-07 23:06 ` Joel Fernandes
2016-07-07 23:47 ` Joel Fernandes
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=alpine.DEB.2.11.1607071653440.4083@nanos \
--to=tglx@linutronix.de \
--cc=agnel.joel@gmail.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®