From: Thomas Gleixner <tglx@linutronix.de>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
x86@kernel.org, Borislav Petkov <bp@alien8.de>,
Yinghai Lu <yinghai@kernel.org>
Subject: [patch 8/8] x86/tsc: Try to adjust TSC if sync test fails
Date: Sat, 19 Nov 2016 13:47:43 -0000 [thread overview]
Message-ID: <20161119134018.048237517@linutronix.de> (raw)
In-Reply-To: 20161119133816.633700010@linutronix.de
[-- Attachment #1: x86-tsc--Try-to-adjust-TSC-if-sync-test-fails.patch --]
[-- Type: text/plain, Size: 5433 bytes --]
If the first CPU of a package comes online, it is necessary to test whether
the TSC is in sync with a CPU on some other package. When a deviation is
observed (time going backward between the two CPUs) the TSC is marked
unstable, which is a problem on large machines as they have to fall back to
the HPET clocksource, which is insanely slow.
It has been attempted to compensate the TSC by adding the offset to the TSC
and writing it back earlier, but it got dropped because it did not turn out
to be stable, especially not on older systems.
Modern systems have become more stable in that regard and the TSC_ADJUST
MSR allows us to compensate for the time deviation in a sane way. If it's
available allow up to three synchronization runs and if a time warp is
detected the starting CPU can compensate the time warp via the TSC_ADJUST
MSR and retry. If the third run still shows a deviation or when random time
warps are detected the test terminally fails.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/x86/kernel/tsc_sync.c | 83 ++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 78 insertions(+), 5 deletions(-)
--- a/arch/x86/kernel/tsc_sync.c
+++ b/arch/x86/kernel/tsc_sync.c
@@ -134,6 +134,7 @@ bool tsc_store_and_check_tsc_adjust(void
static atomic_t start_count;
static atomic_t stop_count;
static atomic_t skip_test;
+static atomic_t test_runs;
/*
* We use a raw spinlock in this exceptional case, because
@@ -254,6 +255,16 @@ void check_tsc_sync_source(int cpu)
}
/*
+ * Set the maximum number of test runs to
+ * 1 if the CPU does not provide the TSC_ADJUST MSR
+ * 3 if the MSR is available, so the target can try to adjust
+ */
+ if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST))
+ atomic_set(&test_runs, 1);
+ else
+ atomic_set(&test_runs, 3);
+retry:
+ /*
* Wait for the target to start or to skip the test:
*/
while (atomic_read(&start_count) != cpus - 1) {
@@ -274,7 +285,21 @@ void check_tsc_sync_source(int cpu)
while (atomic_read(&stop_count) != cpus-1)
cpu_relax();
- if (nr_warps) {
+ /*
+ * If the test was successful set the number of runs to zero and
+ * stop. If not, decrement the number of runs an check if we can
+ * retry. In case of random warps no retry is attempted.
+ */
+ if (!nr_warps) {
+ atomic_set(&test_runs, 0);
+
+ pr_debug("TSC synchronization [CPU#%d -> CPU#%d]: passed\n",
+ smp_processor_id(), cpu);
+
+ } else if (atomic_dec_and_test(&test_runs) || random_warps) {
+ /* Force it to 0 if random warps brought us here */
+ atomic_set(&test_runs, 0);
+
pr_warning("TSC synchronization [CPU#%d -> CPU#%d]:\n",
smp_processor_id(), cpu);
pr_warning("Measured %Ld cycles TSC warp between CPUs, "
@@ -282,9 +307,6 @@ void check_tsc_sync_source(int cpu)
if (random_warps)
pr_warning("TSC warped randomly between CPUs\n");
mark_tsc_unstable("check_tsc_sync_source failed");
- } else {
- pr_debug("TSC synchronization [CPU#%d -> CPU#%d]: passed\n",
- smp_processor_id(), cpu);
}
/*
@@ -300,6 +322,12 @@ void check_tsc_sync_source(int cpu)
* Let the target continue with the bootup:
*/
atomic_inc(&stop_count);
+
+ /*
+ * Retry, if there is a chance to do so.
+ */
+ if (atomic_read(&test_runs) > 0)
+ goto retry;
}
/*
@@ -307,6 +335,9 @@ void check_tsc_sync_source(int cpu)
*/
void check_tsc_sync_target(void)
{
+ struct tsc_adjust *cur = this_cpu_ptr(&tsc_adjust);
+ unsigned int cpu = smp_processor_id();
+ cycles_t cur_max_warp, gbl_max_warp;
int cpus = 2;
/* Also aborts if there is no TSC. */
@@ -322,6 +353,7 @@ void check_tsc_sync_target(void)
return;
}
+retry:
/*
* Register this CPU's participation and wait for the
* source CPU to start the measurement:
@@ -330,7 +362,12 @@ void check_tsc_sync_target(void)
while (atomic_read(&start_count) != cpus)
cpu_relax();
- check_tsc_warp(loop_timeout(smp_processor_id()));
+ cur_max_warp = check_tsc_warp(loop_timeout(cpu));
+
+ /*
+ * Store the maximum observed warp value for a potential retry:
+ */
+ gbl_max_warp = max_warp;
/*
* Ok, we are done:
@@ -347,6 +384,42 @@ void check_tsc_sync_target(void)
* Reset it for the next sync test:
*/
atomic_set(&stop_count, 0);
+
+ /*
+ * Check the number of remaining test runs. If not zero, the test
+ * failed and a retry with adjusted TSC is possible. If zero the
+ * test was either successful or failed terminally.
+ */
+ if (!atomic_read(&test_runs))
+ return;
+
+ /*
+ * If the warp value of this CPU is 0, then the other CPU
+ * observed time going backwards so this TSC was ahead and
+ * needs to move backwards.
+ */
+ if (!cur_max_warp)
+ cur_max_warp = -gbl_max_warp;
+
+ /*
+ * Add the result to the previous adjustment value.
+ *
+ * The adjustement value is slightly off by the overhead of the
+ * sync mechanism (observed values are ~200 TSC cycles), but this
+ * really depends on CPU, node distance and frequency. So
+ * compensating for this is hard to get right. Experiments show
+ * that the warp is not longer detectable when the observed warp
+ * value is used. In the worst case the adjustment needs to go
+ * through a 3rd run for fine tuning.
+ */
+ cur->adjusted += cur_max_warp;
+
+ pr_warn("TSC ADJUST compensate: CPU%u observed %lld warp. Adjust: %lld\n",
+ cpu, cur_max_warp, cur->adjusted);
+
+ wrmsrl(MSR_IA32_TSC_ADJUST, cur->adjusted);
+ goto retry;
+
}
#endif /* CONFIG_SMP */
next prev parent reply other threads:[~2016-11-19 13:50 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-19 13:47 [patch 0/8] x86/tsc: Utilize TSC_ADJUST MSR Thomas Gleixner
2016-11-19 13:47 ` [patch 1/8] x86/tsc: Use X86_FEATURE_TSC_ADJUST in detect_art() Thomas Gleixner
2016-11-29 16:46 ` [tip:x86/timers] " tip-bot for Thomas Gleixner
2016-11-29 18:28 ` tip-bot for Thomas Gleixner
2016-11-19 13:47 ` [patch 2/8] x86/tsc: Detect random warps Thomas Gleixner
2016-11-29 16:46 ` [tip:x86/timers] " tip-bot for Thomas Gleixner
2016-11-29 18:28 ` tip-bot for Thomas Gleixner
2016-11-19 13:47 ` [patch 3/8] x86/tsc: Store and check TSC ADJUST MSR Thomas Gleixner
2016-11-29 16:47 ` [tip:x86/timers] " tip-bot for Thomas Gleixner
2016-11-29 18:29 ` tip-bot for Thomas Gleixner
2017-01-27 13:36 ` [3/8] " Henning Schild
2017-01-30 10:20 ` Thomas Gleixner
2017-01-30 12:13 ` Henning Schild
2017-01-30 13:04 ` Thomas Gleixner
2017-01-30 15:58 ` Borislav Petkov
2016-11-19 13:47 ` [patch 4/8] x86/tsc: Verify TSC_ADJUST from idle Thomas Gleixner
2016-11-20 13:10 ` Peter Zijlstra
2016-11-21 8:16 ` Thomas Gleixner
2016-11-21 11:06 ` Peter Zijlstra
2016-11-29 9:17 ` Thomas Gleixner
2016-11-29 14:25 ` Ingo Molnar
2016-11-21 22:57 ` Andi Kleen
2016-11-29 16:47 ` [tip:x86/timers] " tip-bot for Thomas Gleixner
2016-11-29 18:29 ` tip-bot for Thomas Gleixner
2016-11-19 13:47 ` [patch 5/8] x86/tsc: Sync test only for the first cpu in a package Thomas Gleixner
2016-11-29 16:48 ` [tip:x86/timers] " tip-bot for Thomas Gleixner
2016-11-29 18:30 ` tip-bot for Thomas Gleixner
2016-11-19 13:47 ` [patch 6/8] x86/tsc: Move sync cleanup to a safe place Thomas Gleixner
2016-11-29 16:48 ` [tip:x86/timers] " tip-bot for Thomas Gleixner
2016-11-29 18:30 ` tip-bot for Thomas Gleixner
2016-11-19 13:47 ` [patch 7/8] x86/tsc: Prepare warp test for TSC adjustment Thomas Gleixner
2016-11-29 16:49 ` [tip:x86/timers] " tip-bot for Thomas Gleixner
2016-11-29 18:31 ` tip-bot for Thomas Gleixner
2016-11-19 13:47 ` Thomas Gleixner [this message]
2016-11-29 16:49 ` [tip:x86/timers] x86/tsc: Try to adjust TSC if sync test fails tip-bot for Thomas Gleixner
2016-11-29 18:31 ` tip-bot for Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161119134018.048237517@linutronix.de \
--to=tglx@linutronix.de \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=x86@kernel.org \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.