On Fri, 2026-05-15 at 12:19 -0700, Sean Christopherson wrote: > Prefer the TSC over kvmclock for sched_clock if the TSC is constant, > nonstop, and not marked unstable via command line. I.e. use the same > criteria as tweaking the clocksource rating so that TSC is preferred over > kvmclock. Per the below comment from native_sched_clock(), sched_clock > is more tolerant of slop than clocksource; using TSC for clocksource but > not sched_clock makes little to no sense, especially now that KVM CoCo > guests with a trusted TSC use TSC, not kvmclock. > > /* > * Fall back to jiffies if there's no TSC available: > * ( But note that we still use it if the TSC is marked > * unstable. We do this because unlike Time Of Day, > * the scheduler clock tolerates small errors and it's > * very important for it to be as fast as the platform > * can achieve it. ) > */ > > The only advantage of using kvmclock is that doing so allows for early > and common detection of PVCLOCK_GUEST_STOPPED, but that code has been > broken for over two years with nary a complaint, i.e. it can't be > _that_ valuable. And as above, certain types of KVM guests are losing > the functionality regardless, i.e. acknowledging PVCLOCK_GUEST_STOPPED > needs to be decoupled from sched_clock() no matter what. > > Link: https://lore.kernel.org/all/[email protected] > Signed-off-by: Sean Christopherson <[email protected]>
Yay! (Albeit only for sched_clock, and we should do Xen too) Reviewed-by: David Woodhouse <[email protected]>
smime.p7s
Description: S/MIME cryptographic signature
