[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d37dffa7-c69e-72ed-b777-e7fe742ed5b4@hpe.com>
Date: Wed, 4 Oct 2017 07:15:17 -0700
From: Mike Travis <mike.travis@....com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
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 4/5] x86/kernel: Provide a means to disable TSC ART
On 10/4/2017 2:27 AM, Peter Zijlstra wrote:
> On Mon, Oct 02, 2017 at 10:12:18AM -0500, mike.travis@....com wrote:
>> static void detect_art(void)
>> {
>> unsigned int unused[2];
>>
>> - if (boot_cpu_data.cpuid_level < ART_CPUID_LEAF)
>> + if (boot_cpu_data.cpuid_level < ART_CPUID_LEAF || tsc_art_disabled)
>> return;
>>
>> /* Don't enable ART in a VM, non-stop TSC and TSC_ADJUST required */
>
>
> So why can't we use is_uv_system() here an for the tsc_adjust thing?
I could. I just thought that there may be future system arches that
need the same facility?
>
> Also (and I hate the name) tsc_multi_sync_resets is the reason you
> cannot use ART, I don't think it makes sense to introduce yet another
> knob.
>
Okay. I wasn't sure if there might be different causes for wanting one
condition over the other. So does this mean change this later test to
use is_uv_system() or tsc_multi_sync_resets?
Thanks.
Powered by blists - more mailing lists