Michael Kelley <mikelley@xxxxxxxxxxxxx> writes: > 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. Ok, so it is just a fall-back and not going to be actively used. Thanks! -- Vitaly
