RE: [PATCH v3 2/2] Drivers: hv: Move Hyper-V clocksource code to new clocksource driver
From: Michael Kelley <hidden>
Date: 2019-05-30 12:39:38
Also in:
linux-hyperv, lkml
From: Vitaly Kuznetsov <vkuznets@redhat.com> Sent: Thursday, May 30, 2019 2:48 AM
quoted
+ /* + * 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel