DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C452AAB498
Date: Thu, 29 Jun 2017 11:44:06 -0400
From: Don Zickus <dzickus@redhat.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: "Liang, Kan" <kan.liang@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "mingo@kernel.org" <mingo@kernel.org>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "babu.moger@oracle.com" <babu.moger@oracle.com>,
        "atomlin@redhat.com" <atomlin@redhat.com>,
        "prarit@redhat.com" <prarit@redhat.com>,
        "torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "eranian@google.com" <eranian@google.com>,
        "acme@redhat.com" <acme@redhat.com>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH V2] kernel/watchdog: fix spurious hard lockups
Message-ID: <20170629154406.44xo7dnw7btn4gpx@redhat.com>
References: <20170622154450.2lua7fdmigcixldw@redhat.com>
 <alpine.DEB.2.20.1706230952190.2647@nanos>
 <20170623162907.l6inpxgztwwkeaoi@redhat.com>
 <alpine.DEB.2.20.1706232348020.2234@nanos>
 <20170626201927.3ak7fk3yvdzbb4ay@redhat.com>
 <20170627201249.ll34ecwhpme3vh2u@redhat.com>
 <37D7C6CF3E00A74B8858931C1DB2F0775371357D@SHSMSX103.ccr.corp.intel.com>
 <20170627234822.GL23705@tassilo.jf.intel.com>
 <20170628190008.3ftqq75evhn2hozp@redhat.com>
 <20170628201404.GM23705@tassilo.jf.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170628201404.GM23705@tassilo.jf.intel.com>
User-Agent: NeoMutt/20170428-dirty (1.8.2)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1462
Lines: 39

On Wed, Jun 28, 2017 at 01:14:04PM -0700, Andi Kleen wrote:
> It can be a useful debugging tool for a specific class of bugs: 
> when kernel software is looping forever.
> 
> But if that happens does it really matter how many iterations the
> loop does before it is stopped?
> 
> Even the current timeout is essentially eternity in CPU time, and 3x
> eternity is still eternity.

That isn't true.  We have customers that test the accuracy and file bugs.  I
had to write a RHEL whitepaper a number of years ago explaining why the
softlockup took 62 seconds to fire instead of 60.

Customers were changing the watchdog_thresh when the system slowed down to
purposely trigger a panic (which exposed race conditions leading Uli to
redesign the sysctl interface).

I don't feel like explaining to our customers how we regressed on our
watchdog accuracy.  It is exhausting, especially if it is a debug feature.

> 
> > The hrtimer increase maintains that and just adds a few more
> > interrupts/second.
> 
> Interruptions are a big deal for many people.

Yes, and we probably have customers that will complain on that too.

Either solution is a lose/lose.  And yes, we will probably get bit by the
false NMI problems on those Intel boxes.  This is why I was preferring a
real solution.

The question is, if the real solution is going to take a while, what is the
least sucky solution for now?  Or how do we minimize it to a specific class
of Intel boxes.

Cheers,
Don