lkml.org 
[lkml]   [2022]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2023-03-26 23:17    [W:0.065 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site