Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753794AbbHRRtZ (ORCPT ); Tue, 18 Aug 2015 13:49:25 -0400 Received: from mail-io0-f171.google.com ([209.85.223.171]:34258 "EHLO mail-io0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751303AbbHRRtY (ORCPT ); Tue, 18 Aug 2015 13:49:24 -0400 MIME-Version: 1.0 In-Reply-To: References: <1439844063-7957-1-git-send-email-john.stultz@linaro.org> <1439844063-7957-9-git-send-email-john.stultz@linaro.org> Date: Tue, 18 Aug 2015 10:49:23 -0700 Message-ID: Subject: Re: [PATCH 8/9] clocksource: Improve unstable clocksource detection From: John Stultz To: Thomas Gleixner Cc: lkml , Shaohua Li , Prarit Bhargava , Richard Cochran , Daniel Lezcano , Ingo Molnar Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1887 Lines: 43 On Tue, Aug 18, 2015 at 1:38 AM, Thomas Gleixner wrote: > On Mon, 17 Aug 2015, John Stultz wrote: >> On Mon, Aug 17, 2015 at 3:04 PM, Thomas Gleixner wrote: >> > On Mon, 17 Aug 2015, John Stultz wrote: >> > >> >> From: Shaohua Li >> >> >> >> >From time to time we saw TSC is marked as unstable in our systems, while >> > >> > Stray '>' >> > >> >> the CPUs declare to have stable TSC. Looking at the clocksource unstable >> >> detection, there are two problems: >> >> - watchdog clock source wrap. HPET is the most common watchdog clock >> >> source. It's 32-bit and runs in 14.3Mhz. That means the hpet counter >> >> can wrap in about 5 minutes. >> >> - threshold isn't scaled against interval. The threshold is 0.0625s in >> >> 0.5s interval. What if the actual interval is bigger than 0.5s? >> >> >> >> The watchdog runs in a timer bh, so hard/soft irq can defer its running. >> >> Heavy network stack softirq can hog a cpu. IPMI driver can disable >> >> interrupt for a very long time. >> > >> > And they hold off the timer softirq for more than a second? Don't you >> > think that's the problem which needs to be fixed? >> >> Though this is an issue I've experienced (and tried unsuccessfully to >> fix in a more complicated way) with the RT kernel, where high priority >> tasks blocked the watchdog long enough that we'd disqualify the TSC. > > Did it disqualify the watchdog due to HPET wraparounds (5 minutes) or > due to the fixed threshold being applied? This was years ago, but in my experience, the watchdog false positives were due to HPET wraparounds. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/