On Mon, Oct 02, 2023 at 11:06:07PM +0200, Peter Zijlstra wrote: > On Mon, Oct 02, 2023 at 11:18:50AM -0700, Sean Christopherson wrote: > > +PeterZ > > > > Thomas and Peter, > > > > We're trying to address an issue where KVM's paravirt kvmclock drifts from the > > host's TSC-based monotonic raw clock because of historical reasons (at least, AFAICT), > > even when the TSC is constant. Due to some dubious KVM behavior, KVM may sometimes > > re-sync kvmclock against the host's monotonic raw clock, which causes non-trivial > > jumps in time from the guest's perspective. > > > > Linux-as-a-guest demotes all paravirt clock sources when the TSC is constant and > > nonstop, and so the goofy KVM behavior isn't likely to affect the guest's clocksource, > > but the guest's sched_clock() implementation keeps using the paravirt clock. > > > > Irrespective of if/how we fix the KVM host-side mess, using a paravirt clock for > > the scheduler when using a constant, nonstop TSC for the clocksource seems at best > > inefficient, and at worst unnecessarily complex and risky. > > > > Is there any reason not to prefer native_sched_clock() over whatever paravirt > > clock is present when the TSC is the preferred clocksource? > > I see none, that whole pv_clock thing is horrible crap. In fact, I don't really see a reason to ever use pv_clock, even on non-constant TSC. The sched_clock machinery used on x86 (and ia64 at some point) reverts to tick-based + 'TSC-with-monotonicity-filter refinement' once it detects the TSC is crap. And that should work in a guest too I suppose. Also, I really should clean all that up -- it's all static_key based, but I think I can do a saner version with static_call. But that's stuck somewhere on the eternal todo list.
