[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20230131012440.GA1251465@paulmck-ThinkPad-P17-Gen-1>
Date: Mon, 30 Jan 2023 17:24:40 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: tglx@...utronix.de, daniel.lezcano@...aro.org
Cc: linux-kernel@...r.kernel.org, john.stultz@...aro.org,
sboyd@...nel.org, corbet@....net, Mark.Rutland@....com,
maz@...nel.org, kernel-team@...a.com, neeraju@...eaurora.org,
ak@...ux.intel.com, feng.tang@...el.com, zhengjun.xing@...el.com
Subject: [GIT PULL clocksource] Clocksource watchdog commits for v6.3]
Hello, Thomas,
The following changes since commit 1b929c02afd37871d5afb9d498426f83432e71c2:
Linux 6.2-rc1 (2022-12-25 13:41:39 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git tags/clocksource.2023.01.30a
for you to fetch changes up to 39836ec34f4698cfc80df4b2953e10fb9fa03506:
x86/tsc: Add option to force frequency recalibration with HW timer (2023-01-24 15:18:36 -0800)
----------------------------------------------------------------
Clocksource watchdog commits for v6.3
This pull request contains the following:
o Improvements to clocksource-watchdog console messages.
o Loosening of the clocksource-watchdog skew criteria to match
those of NTP (500 parts per million, relaxed from 400 parts
per million). If it is good enough for NTP, it is good enough
for the clocksource watchdog.
o Suspend clocksource-watchdog checking temporarily when high
memory latencies are detected. This avoids the false-positive
clock-skew events that have been seen on production systems
running memory-intensive workloads.
o On systems where the TSC is deemed trustworthy, use it as the
watchdog timesource. This permits clock-skew events to be
detected, but avoids forcing workloads to use the slow HPET
and ACPI PM timers. These last two timers are slow enough to
cause systems to be needlessly marked bad on the one hand, and
real skew does sometimes happen on production systems running
production workloads on the other. And sometimes it is the fault
of the TSC, or at least of the firmware that told the kernel to
program the TSC with the wrong frequency.
o Add a tsc=revalidate kernel boot parameter to allow the kernel
to diagnose cases where the TSC hardware works fine, but was told
by firmware to tick at the wrong frequency. Such cases are rare,
but they really have happened on production systems.
----------------------------------------------------------------
Feng Tang (2):
clocksource: Suspend the watchdog temporarily when high read latency detected
x86/tsc: Add option to force frequency recalibration with HW timer
Paul E. McKenney (4):
clocksource: Loosen clocksource watchdog constraints
clocksource: Improve read-back-delay message
clocksource: Improve "skew is too large" messages
clocksource: Verify HPET and PMTMR when TSC unverified
Yunying Sun (1):
clocksource: Print clocksource name when clocksource is tested unstable
Documentation/admin-guide/kernel-parameters.txt | 4 ++
arch/x86/include/asm/time.h | 1 +
arch/x86/kernel/hpet.c | 2 +
arch/x86/kernel/tsc.c | 39 ++++++++++++--
drivers/clocksource/acpi_pm.c | 6 ++-
kernel/time/Kconfig | 6 ++-
kernel/time/clocksource.c | 72 +++++++++++++++++--------
7 files changed, 102 insertions(+), 28 deletions(-)
Powered by blists - more mailing lists