On Tue, 18 Aug 2015, John Stultz wrote: > On Tue, Aug 18, 2015 at 1:38 AM, Thomas Gleixner <[email protected]> wrote: > > On Mon, 17 Aug 2015, John Stultz wrote: > >> On Mon, Aug 17, 2015 at 3:04 PM, Thomas Gleixner <[email protected]> > >> wrote: > >> > On Mon, 17 Aug 2015, John Stultz wrote: > >> > > >> >> From: Shaohua Li <[email protected]> > >> >> > >> >> >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.
Blocking stuff for 5 minutes is insane .... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
