On 10/12/2017 4:17 AM, Thomas Gleixner wrote:
On Thu, 5 Oct 2017, mike.tra...@hpe.com wrote:
If the TSC has already been determined to be unstable, then checking
TSC ADJUST values is a waste of time and generates unnecessary error
messages.
Signed-off-by: Mike Travis <mike.tra...@hpe.com>
Reviewed-by: Dimitri Sivanich <dimitri.sivan...@hpe.com>
Reviewed-by: Russ Anderson <russ.ander...@hpe.com>
Reviewed-by: Peter Zijlstra <pet...@infradead.org>
---
arch/x86/kernel/tsc_sync.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- linux.orig/arch/x86/kernel/tsc_sync.c
+++ linux/arch/x86/kernel/tsc_sync.c
@@ -38,6 +38,10 @@ void tsc_verify_tsc_adjust(bool resume)
if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST))
return;
+ /* Skip unnecessary error messages if TSC already unstable */
+ if (check_tsc_unstable())
+ return;
+
/* Rate limit the MSR check */
if (!resume && time_before(jiffies, adj->nextcheck))
return;
@@ -89,6 +93,10 @@ bool tsc_store_and_check_tsc_adjust(bool
if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST))
return false;
+ /* Skip unnecessary error messages if TSC already unstable */
+ if (check_tsc_unstable())
+ return false;
+
rdmsrl(MSR_IA32_TSC_ADJUST, bootval);
cur->bootval = bootval;
cur->adjusted = bootval;
This hunk rejects and I really can't figure out against which tree that
would apply.
My current merge tree happens to be 4.13.0-rc1 which was the latest when
I started this patch submission. I can update my merge tree and reapply
if need be?
Btw, there are two incarnations of tsc_store_and_check_tsc_adjust().
Shouldn't the !SMP variant get the same treatment?
I could add it though I'm not sure the point? If it's only one CPU
would TSC's being out of sync become a question?
Thanks,
tglx
