Messages in this thread | | | Date | Wed, 21 Dec 2022 21:55:15 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [RFC PATCH] clocksource: Suspend the watchdog temporarily when high read lantency detected |
| |
On Wed, Dec 21, 2022 at 10:39:53PM -0500, Waiman Long wrote: > On 12/21/22 19:40, Paul E. McKenney wrote: > > commit 199dfa2ba23dd0d650b1482a091e2e15457698b7 > > Author: Paul E. McKenney<paulmck@kernel.org> > > Date: Wed Dec 21 16:20:25 2022 -0800 > > > > clocksource: Verify HPET and PMTMR when TSC unverified > > On systems with two or fewer sockets, when the boot CPU has CONSTANT_TSC, > > NONSTOP_TSC, and TSC_ADJUST, clocksource watchdog verification of the > > TSC is disabled. This works well much of the time, but there is the > > occasional system that meets all of these criteria, but which still > > has a TSC that skews significantly from atomic-clock time. This is > > usually attributed to a firmware or hardware fault. Yes, the various > > NTP daemons do express their opinions of userspace-to-atomic-clock time > > skew, but they put them in various places, depending on the daemon and > > distro in question. It would therefore be good for the kernel to have > > some clue that there is a problem. > > The old behavior of marking the TSC unstable is a non-starter because a > > great many workloads simply cannot tolerate the overheads and latencies > > of the various non-TSC clocksources. In addition, NTP-corrected systems > > often seem to be able to tolerate significant kernel-space time skew as > > long as the userspace time sources are within epsilon of atomic-clock > > time. > > Therefore, when watchdog verification of TSC is disabled, enable it for > > HPET and PMTMR (AKA ACPI PM timer). This provides the needed in-kernel > > time-skew diagnostic without degrading the system's performance. > > Signed-off-by: Paul E. McKenney<paulmck@kernel.org> > > Cc: Thomas Gleixner<tglx@linutronix.de> > > Cc: Ingo Molnar<mingo@redhat.com> > > Cc: Borislav Petkov<bp@alien8.de> > > Cc: Dave Hansen<dave.hansen@linux.intel.com> > > Cc: "H. Peter Anvin"<hpa@zytor.com> > > Cc: Daniel Lezcano<daniel.lezcano@linaro.org> > > Cc: Feng Tang<feng.tang@intel.com> > > Cc: Waiman Long <longman@redhat.com > > Cc:<x86@kernel.org> > > As I currently understand, you are trying to use TSC as a watchdog to check > against HPET and PMTMR. I do have 2 questions about this patch. > > First of all, why you need to use both HPET and PMTMR? Can you just use one > of those that are available. Secondly, is it possible to enable this > time-skew diagnostic for a limit amount of time instead running > indefinitely? The running of the clocksource watchdog itself will still > consume a tiny amount of CPU cycles.
I could certainly do something so that only the first of HPET and PMTMR is checked. Could you give me a quick run-through of the advantages of using only one? I would need to explain that in the commit log.
Would it make sense to have a kernel boot variable giving the number of minutes for which the watchdog was to run, with a default of zero meaning "indefinitely"?
Thanx, Paul
| |