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.tra...@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
