All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Galbraith <umgwanakikbuti@gmail.com>
To: "Jörn Engel" <joern@purestorage.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: Wed, 22 Jul 2015 07:41:48 +0200	[thread overview]
Message-ID: <1437543708.3106.70.camel@gmail.com> (raw)
In-Reply-To: <20150722051827.GD23662@Sligo.logfs.org>

On Tue, 2015-07-21 at 22:18 -0700, Jörn Engel wrote:
> On Wed, Jul 22, 2015 at 06:36:30AM +0200, Mike Galbraith wrote:
> > On Tue, 2015-07-21 at 15:07 -0700, Spencer Baugh wrote:
> > 
> > > We have observed cases where the soft lockup detector triggered, but no
> > > kernel bug existed.  Instead we had a buggy realtime thread that
> > > monopolized a cpu.  So let's kill the responsible party and not panic
> > > the entire system.
> > 
> > If you don't tell the kernel to panic, it won't, and if you don't remove
> > its leash (the throttle), your not so tame rt beast won't maul you.
> 
> 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.
 
> And the realtime throttling gives non-realtime threads some minimum
> runtime, but does nothing to help low-priority realtime threads.  It
> also introduces latencies, often when workloads are high and you would
> like any available cpu to get through that rough spot.

You can use group scheduling as a debug crutch until the little beasts
are housebroken.

> I don't think we have a good answer to this problem in the mainline
> kernel yet.

IMHO, there's no point in trying to make rt warm/fuzzy/cuddly.  Just
don't stuff a Hells Angel into a super-suit, that gets real ugly ;-)

	-Mike


  reply	other threads:[~2015-07-22  5:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-21 22:07 [PATCH] soft lockup: kill realtime threads before panic Spencer Baugh
2015-07-22  4:36 ` Mike Galbraith
2015-07-22  5:18   ` Jörn Engel
2015-07-22  5:41     ` Mike Galbraith [this message]
2015-07-22  6:33       ` Jörn Engel
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=1437543708.3106.70.camel@gmail.com \
    --to=umgwanakikbuti@gmail.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=joern@purestorage.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=sbaugh@catern.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 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.