RE: [PATCH v3 2/2] Drivers: hv: Move Hyper-V clocksource code to new clocksource driver
From: Michael Kelley
Date: Thu May 30 2019 - 08:43:12 EST
From: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> Sent: Thursday, May 30, 2019 2:48 AM
> > + /*
> > + * sched_clock_register is needed on ARM64 but
> > + * is a no-op on x86
> > + */
> > + sched_clock_register(read_hv_sched_clock_msr,
> > + 64, HV_CLOCK_HZ);
>
> I'm not sure about ARM, but MSR-based clocksource would be a really bad
> choice for sched clock on x86, this will slow things down
> significantly. Luckily, as you're validly stating above,
> sched_clock_register() is a no-op on x86 as we don't define
> CONFIG_GENERIC_SCHED_CLOCK.
>
> Can we actually *not* do sched_clock_register() in case
> TSC page is unavailable (and revert to counting jiffies or whatever)?
>
We can't skip the sched_clock_register() on ARM64 because it
does define CONFIG_GENERIC_SCHED_CLOCK. However, Hyper-V
should always provide REFERENCE_TSC_AVAILALBE on ARM64,
so we should never end up in the MSR-based code on ARM64.
Arguably that means the call to sched_clock_register() could be
removed since it's a no-op on x86. But I'd like to keep it for symmetry
and in case there's a testing/debugging situation on ARM64 where
we want to clear REFERENCE_TSC_AVAILABLE and go down the
MSR-based code path.
Michael