From: "Jörn Engel" <joern@purestorage.com>
To: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: Spencer Baugh <sbaugh@catern.com>,
Don Zickus <dzickus@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Ulrich Obergfell <uobergfe@redhat.com>,
Ingo Molnar <mingo@kernel.org>, Andrew Jones <drjones@redhat.com>,
chai wen <chaiw.fnst@cn.fujitsu.com>,
Chris Metcalf <cmetcalf@ezchip.com>,
Stephane Eranian <eranian@google.com>,
open list <linux-kernel@vger.kernel.org>,
Spencer Baugh <Spencer.baugh@purestorage.com>,
Joern Engel <joern@logfs.org>
Subject: Re: [PATCH] soft lockup: kill realtime threads before panic
Date: Tue, 21 Jul 2015 23:33:23 -0700 [thread overview]
Message-ID: <20150722063323.GE23662@Sligo.logfs.org> (raw)
In-Reply-To: <1437543708.3106.70.camel@gmail.com>
On Wed, Jul 22, 2015 at 07:41:48AM +0200, Mike Galbraith wrote:
> On Tue, 2015-07-21 at 22:18 -0700, Jörn Engel wrote:
> >
> > Not sure if this patch is something for mainline, but those two
> > alternatives have problems of their own. Not panicking on lockups can
> > leave a system disabled until some human come around. In many cases
> > that human will do no better than power-cycle. A panic reduces the
> > downtime.
>
> If a realtime task goes bonkers, the realtime game is over, you're down.
Agreed. But a reboot will often solve the issue. So the automatic
panic will repair the system within minutes, while no panic will leave
the system broken for days, depending on human response time. Automatic
panic is a great way to minimize downtime - or vulnerable time if you
have HA.
One could argue that killing the realtime thread is even better than
panic, as things can restart with a blank slate even faster. But the
real benefit is that we get better debug data for the failing component.
If we had a kernel bug, the backtrace would usually be sufficient to
point fingers. With a bonkers realtime thread, not so much.
Anyway, this patch has been useful to us once. If someone deems it
merge-worthy, great. If not, I won't lose any sleep either.
Jörn
--
The key to performance is elegance, not battalions of special cases.
-- Jon Bentley and Doug McIlroy
next prev parent reply other threads:[~2015-07-22 6:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-21 22:07 Spencer Baugh
2015-07-22 4:36 ` Mike Galbraith
2015-07-22 5:18 ` Jörn Engel
2015-07-22 5:41 ` Mike Galbraith
2015-07-22 6:33 ` Jörn Engel [this message]
2015-07-22 7:35 ` Mike Galbraith
2015-07-22 13:52 ` Don Zickus
2015-07-22 16:35 ` Jörn Engel
2015-07-22 6:59 ` yalin wang
2015-07-22 22:54 ` Andrew Morton
2015-07-22 23:29 ` Jörn Engel
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=20150722063323.GE23662@Sligo.logfs.org \
--to=joern@purestorage.com \
--cc=Spencer.baugh@purestorage.com \
--cc=akpm@linux-foundation.org \
--cc=chaiw.fnst@cn.fujitsu.com \
--cc=cmetcalf@ezchip.com \
--cc=drjones@redhat.com \
--cc=dzickus@redhat.com \
--cc=eranian@google.com \
--cc=joern@logfs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=sbaugh@catern.com \
--cc=umgwanakikbuti@gmail.com \
--cc=uobergfe@redhat.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 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®