Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752586AbdFVPd3 (ORCPT ); Thu, 22 Jun 2017 11:33:29 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:56388 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751185AbdFVPd2 (ORCPT ); Thu, 22 Jun 2017 11:33:28 -0400 Date: Thu, 22 Jun 2017 17:33:02 +0200 (CEST) From: Thomas Gleixner To: Kan Liang cc: LKML , dzickus@redhat.com, Ingo Molnar , Andrew Morton , babu.moger@oracle.com, atomlin@redhat.com, Prarit Bhargava , Linus Torvalds , Peter Zijlstra , eranian@google.com, Arnaldo Carvalho de Melo , ak@linux.intel.com, stable@vger.kernel.org Subject: Re: [PATCH V2] kernel/watchdog: fix spurious hard lockups In-Reply-To: Message-ID: References: <20170621144118.5939-1-kan.liang@intel.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1012 Lines: 24 On Wed, 21 Jun 2017, Thomas Gleixner wrote: > On Wed, 21 Jun 2017, kan.liang@intel.com wrote: > > We now have more and more systems where the Turbo range is wide enough > > that the NMI watchdog expires faster than the soft watchdog timer that > > updates the interrupt tick the NMI watchdog relies on. > > > > This problem was originally added by commit 58687acba592 > > ("lockup_detector: Combine nmi_watchdog and softlockup detector"). > > Previously the NMI watchdog would always check jiffies, which were > > ticking fast enough. But now the backing is quite slow so the expire > > time becomes more sensitive. > > And slapping a factor 3 on the NMI period is the wrong answer to the > problem. The simple solution would be to increase the hrtimer frequency, > but that's not really desired either. Thinking a bit more about it. Increasing the hrtimer frequency and maintaining the current frequency of softlockup_watchdog wakeups, would be probably the most trivial workaround for now. Thanks, tglx