From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751572AbdF1TAb (ORCPT ); Wed, 28 Jun 2017 15:00:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38678 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752120AbdF1TAQ (ORCPT ); Wed, 28 Jun 2017 15:00:16 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6A7083DEE4 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dzickus@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 6A7083DEE4 Date: Wed, 28 Jun 2017 15:00:08 -0400 From: Don Zickus To: Andi Kleen Cc: "Liang, Kan" , Thomas Gleixner , "linux-kernel@vger.kernel.org" , "mingo@kernel.org" , "akpm@linux-foundation.org" , "babu.moger@oracle.com" , "atomlin@redhat.com" , "prarit@redhat.com" , "torvalds@linux-foundation.org" , "peterz@infradead.org" , "eranian@google.com" , "acme@redhat.com" , "stable@vger.kernel.org" Subject: Re: [PATCH V2] kernel/watchdog: fix spurious hard lockups Message-ID: <20170628190008.3ftqq75evhn2hozp@redhat.com> References: <20170621144118.5939-1-kan.liang@intel.com> <20170622154450.2lua7fdmigcixldw@redhat.com> <20170623162907.l6inpxgztwwkeaoi@redhat.com> <20170626201927.3ak7fk3yvdzbb4ay@redhat.com> <20170627201249.ll34ecwhpme3vh2u@redhat.com> <37D7C6CF3E00A74B8858931C1DB2F0775371357D@SHSMSX103.ccr.corp.intel.com> <20170627234822.GL23705@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170627234822.GL23705@tassilo.jf.intel.com> User-Agent: NeoMutt/20170428-dirty (1.8.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 28 Jun 2017 19:00:10 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 27, 2017 at 04:48:22PM -0700, Andi Kleen wrote: > > I haven't heard back any test result yet. > > > > The above patch looks good to me. > > This needs performance testing. It may slow down performance or latency sensitive workloads. More motivation to work through the issues with the proposed real fix? :-) > > > Which workaround do you prefer, the above one or the one checking timestamp? > > I prefer the earlier patch, it has far less risk of performance issues. But now you are slowing down the nmi_watchdog so much that the watchdog_thresh hold becomes meaningless, no? (granted the turbo-mode blows it out of the water too) So now folks who depend on the 10/5/1/whatever second reliability lose that. I think that might be unfair too. The hrtimer increase maintains that and just adds a few more interrupts/second. Cheers, Don