Is there a way to recalibrate the x86 TSC during a suspend/resume cycle? While the frequency will remain the same on a Laptop, it may (or rather: it definitly will) differ if a VM is migrated from one host to another. The hypervisor may choose to emulate the expected TSC frequency on the destination host, but this emulation comes with a significant performance cost. Therefore it would be good if the kernel evaluates the environment during resume.
The specific usecase I have is a workload within VMs that makes heavy use of TSC. The kernel is booted with 'clocksource=tsc highres=off nohz=off' because only this clocksource gives enough granularity. The default paravirtualized clock will return the same values via clock_gettime(CLOCK_MONOTONIC) if the timespan between two calls is too short. This does not happen with 'clocksource=tsc'. Right now it is not possible to migrate VMs to hosts with different CPU speeds. This leads to "islands" of identical hardware, and makes maintenance of hosts harder than it needs to be. If the VM kernel would be able to cope with CPU/TSC frequency changes, the pool of potential destination hosts will become significant larger. The current result of a migration with non-emulated TSC between hosts of different speed is: [ 42.452258] clocksource: timekeeping watchdog on CPU1: Marking clocksource 'tsc' as unstable because the skew is too large: [ 42.452270] clocksource: 'xen' wd_now: 6d34a86adb wd_last: 6d1dc51793 mask: ffffffffffffffff [ 42.452272] clocksource: 'tsc' cs_now: 1fd2ce46bb cs_last: 1f95c4ca75 mask: ffffffffffffffff [ 42.452273] tsc: Marking TSC unstable due to clocksource watchdog Thanks, Olaf
signature.asc
Description: PGP signature
