[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140818151737.GT49576@redhat.com>
Date: Mon, 18 Aug 2014 11:17:37 -0400
From: Don Zickus <dzickus@...hat.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: akpm@...ux-foundation.org, kvm@...r.kernel.org,
pbonzini@...hat.com, mingo@...hat.com,
LKML <linux-kernel@...r.kernel.org>,
Ulrich Obergfell <uobergfe@...hat.com>,
Andrew Jones <drjones@...hat.com>
Subject: Re: [PATCH 4/5] watchdog: control hard lockup detection default
On Mon, Aug 18, 2014 at 11:16:44AM +0200, Ingo Molnar wrote:
>
> * Don Zickus <dzickus@...hat.com> wrote:
>
> > The running kernel still has the ability to enable/disable at any
> > time with /proc/sys/kernel/nmi_watchdog us usual. However even
> > when the default has been overridden /proc/sys/kernel/nmi_watchdog
> > will initially show '1'. To truly turn it on one must disable/enable
> > it, i.e.
> > echo 0 > /proc/sys/kernel/nmi_watchdog
> > echo 1 > /proc/sys/kernel/nmi_watchdog
>
> This looks like a bug, why is this so?
It is, but it always has been there in the case of the PMU not being able
to provide a resource for the hardlockup. This change just exposes it
more.
Originally I wrote the code to keep the softlockup and hardlockup in sync.
Now this patch attempts to split it up because the guest PMU is still
flushing out bugs.
The above scenario only really applies to developers. Their guest boots
up with the hardlockup disabled. If they want to enable it to debug or
develop, they have to go with the above steps. The idea is once the KVM
PMU is stable enough, the default switches to hardlockup enabled by
default and this problem kinda goes back to one it is today.
I guess I was feeling lazy about modifying a bunch of code to separate the
hard and soft lockup for a temporarily broken feature. :-/
I thought it would just be easier to put this code in to quickly stabilize
their PMU and switch the default later.
Thoughts? I think Uli laid out a more detailed example in his email.
Cheers,
Don
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists