]> git.baikalelectronics.ru Git - kernel.git/commit
tick/common: Make tick_periodic() check for missing ticks
authorWaiman Long <longman@redhat.com>
Fri, 7 Feb 2020 19:39:29 +0000 (14:39 -0500)
committerThomas Gleixner <tglx@linutronix.de>
Wed, 4 Mar 2020 09:18:11 +0000 (10:18 +0100)
commitf392ab988bdb68a0a14779b847e0da1e6b6bbedd
tree921ce6611cb4e44ed4dc8f08ea56e70f81b7dab0
parentadb3e9d021a52fbd919e1ca361b434a17f0e7d58
tick/common: Make tick_periodic() check for missing ticks

The tick_periodic() function is used at the beginning part of the
bootup process for time keeping while the other clock sources are
being initialized.

The current code assumes that all the timer interrupts are handled in
a timely manner with no missing ticks. That is not actually true. Some
ticks are missed and there are some discrepancies between the tick time
(jiffies) and the timestamp reported in the kernel log.  Some systems,
however, are more prone to missing ticks than the others.  In the extreme
case, the discrepancy can actually cause a soft lockup message to be
printed by the watchdog kthread. For example, on a Cavium ThunderX2
Sabre arm64 system:

 [   25.496379] watchdog: BUG: soft lockup - CPU#14 stuck for 22s!

On that system, the missing ticks are especially prevalent during the
smp_init() phase of the boot process. With an instrumented kernel,
it was found that it took about 24s as reported by the timestamp for
the tick to accumulate 4s of time.

Investigation and bisection done by others seemed to point to the
commit b5e63f7dafef ("arm64: Advertise mitigation of Spectre-v2, or
lack thereof") as the culprit. It could also be a firmware issue as
new firmware was promised that would fix the issue.

To properly address this problem, stop assuming that there will be no
missing tick in tick_periodic(). Modify it to follow the example of
tick_do_update_jiffies64() by using another reference clock to check for
missing ticks. Since the watchdog timer uses running_clock(), it is used
here as the reference. With this applied, the soft lockup problem in the
affected arm64 system is gone and tick time tracks much more closely to the
timestamp time.

Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20200207193929.27308-1-longman@redhat.com
kernel/time/tick-common.c