[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <726db3a9-3607-3105-770a-d5e5927b1874@hpe.com>
Date: Thu, 12 Oct 2017 08:17:34 -0700
From: Mike Travis <mike.travis@....com>
To: Thomas Gleixner <tglx@...utronix.de>
CC: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Bin Gao <bin.gao@...ux.intel.com>,
"Prarit Bhargava" <prarit@...hat.com>,
Dimitri Sivanich <dimitri.sivanich@....com>,
Andrew Banman <andrew.banman@....com>,
Russ Anderson <russ.anderson@....com>,
<linux-kernel@...r.kernel.org>, <x86@...nel.org>
Subject: Re: [PATCH 2/5] x86/kernel: Skip TSC test and error messages if
already unstable
On 10/12/2017 4:17 AM, Thomas Gleixner wrote:
> On Thu, 5 Oct 2017, mike.travis@....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.travis@....com>
>> Reviewed-by: Dimitri Sivanich <dimitri.sivanich@....com>
>> Reviewed-by: Russ Anderson <russ.anderson@....com>
>> Reviewed-by: Peter Zijlstra <peterz@...radead.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
>
Powered by blists - more mailing lists