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
