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.
Btw, there are two incarnations of tsc_store_and_check_tsc_adjust().
Shouldn't the !SMP variant get the same treatment?
Thanks,
tglx
