Messages in this thread | | | Date | Wed, 4 Oct 2017 20:50:20 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [PATCH 4/5] x86/kernel: Provide a means to disable TSC ART |
| |
On Wed, 4 Oct 2017, Mike Travis wrote: > On 10/4/2017 2:27 AM, Peter Zijlstra wrote: > > On Mon, Oct 02, 2017 at 10:12:18AM -0500, mike.travis@hpe.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?
tsc_multi_sync_resets because that's the reason to disable ART as not all sockets have the same TSC <-> ART offset.
Btw, your changelog is slightly wrong here:
> On systems where multiple chassis are reset asynchronously there is not a > constant ratio between the ART frequency and the TSC time that can be > provided by the boot cpu.
The ratio is actually the same as the frequencies should be the same. Though the offset in that equation:
n TSC = offset + ART * --- d
is different because that offset is basically TSC_ADJUST.
Thanks,
tglx
| |