DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 4A4481AD5C5
Date: Thu, 29 Jun 2017 12:26:18 -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: <20170629162618.exjllikxeac3ujih@redhat.com>
References: <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>
 <20170629154406.44xo7dnw7btn4gpx@redhat.com>
 <20170629161220.GN23705@tassilo.jf.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170629161220.GN23705@tassilo.jf.intel.com>
User-Agent: NeoMutt/20170428-dirty (1.8.2)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1531
Lines: 43

On Thu, Jun 29, 2017 at 09:12:20AM -0700, Andi Kleen wrote:
> On Thu, Jun 29, 2017 at 11:44:06AM -0400, Don Zickus wrote:
> > 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.
> 
> Ok that makes sense.
> 
> It seems like a broken QA test from your customer, not a real issue, 

Agreed.

> but yes explaining and documenting that can be difficult.

Yes.

> 
> > 
> > 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.
> 
> You can't minimize it because there's no forward looking solution
> to detect a large turbo range, and also whatever issue you have in the
> generic case would apply to them too.
> 
> Thomas' patch to modulate the frequency seemed reasonable to me.
> It made the NMI watchdog depend on accurate ktime, but that's probably ok.

Ok, did Kan finish testing this patch (with the small fix on top)?

Cheers,
Don