Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753422AbdF0UMz (ORCPT ); Tue, 27 Jun 2017 16:12:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51360 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752646AbdF0UMv (ORCPT ); Tue, 27 Jun 2017 16:12:51 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C47D38553E Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dzickus@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C47D38553E Date: Tue, 27 Jun 2017 16:12:49 -0400 From: Don Zickus To: Thomas Gleixner , Kan Liang Cc: 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, ak@linux.intel.com, stable@vger.kernel.org Subject: Re: [PATCH V2] kernel/watchdog: fix spurious hard lockups Message-ID: <20170627201249.ll34ecwhpme3vh2u@redhat.com> References: <20170621144118.5939-1-kan.liang@intel.com> <20170622154450.2lua7fdmigcixldw@redhat.com> <20170623162907.l6inpxgztwwkeaoi@redhat.com> <20170626201927.3ak7fk3yvdzbb4ay@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170626201927.3ak7fk3yvdzbb4ay@redhat.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.28]); Tue, 27 Jun 2017 20:12:51 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1205 Lines: 36 On Mon, Jun 26, 2017 at 04:19:27PM -0400, Don Zickus wrote: > On Fri, Jun 23, 2017 at 11:50:25PM +0200, Thomas Gleixner wrote: > > On Fri, 23 Jun 2017, Don Zickus wrote: > > > Hmm, all this work for a temp fix. Kan, how much longer until the real fix > > > of having perf count the right cycles? > > > > Quite a while. The approach is wilfully breaking the user space ABI, which > > is not going to happen. > > > > And there is a simpler solution as well, as I said here: > > > > http://lkml.kernel.org/r/alpine.DEB.2.20.1706221730520.1885@nanos > > Hi Thomas, > > So, you are saying instead of slowing down the perf counter, speed up the > hrtimer to sample more frequently like so: > > diff --git a/kernel/watchdog.c b/kernel/watchdog.c > index 03e0b69..8ff49de 100644 > --- a/kernel/watchdog.c > +++ b/kernel/watchdog.c > @@ -160,7 +160,7 @@ static void set_sample_period(void) > * and hard thresholds) to increment before the > * hardlockup detector generates a warning > */ > - sample_period = get_softlockup_thresh() * ((u64)NSEC_PER_SEC / 5); > + sample_period = get_softlockup_thresh() * ((u64)NSEC_PER_SEC / 10); > } Hi Kan, Will the above patch work for you? Cheers, Don