Re: [PATCH 1/5] Add a global synchronization point for pvclock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/21/2010 03:01 AM, Zachary Amsden wrote:
on this machine Glauber mentioned, or even on a multi-core Core 2 Duo),
but the delta calculation is very hard (if not impossible) to get right.

The timewarps i've seen were in the 0-200ns range, and very rare (once
every 10 minutes or so).

Might be due to NMIs or SMIs interrupting the rdtsc(); ktime_get() operation which establishes the timeline. We could limit it by having a loop doing rdtsc(); ktime_get(); rdtsc(); and checking for some bound, but it isn't worthwhile (and will break nested virtualization for sure). Better to have the option to calibrate kvmclock just once on machines with X86_FEATURE_NONSTOP_TRULY_RELIABLE _TSC_HONESTLY.
Yes. So its not as if the guest visible TSCs go out of sync (they don't

There's a perfect way to do this and it still fails to stop timewarps. You can set the performance counters to overflow if more instructions are issued than your code path, run an assembly instruction stream and if the performance interrupt hits, restart the calibration.

It's completely impractical. The PMU is a global resource that is already shared among users and the host; programming and restoring it is expensive; and in a virtualized environment it the whole scheme may fail.


The calibration happens not just once, but on every migration, and currently, I believe, on every VCPU switch. Even if we reduce the number of calibrations to the bare minimum and rule out SMIs and NMIs, there will still be variation due to factors beyond our control because of the unpredictable nature of cache and instruction issue.

Right.


However, X86_FEATURE_NONSTOP_TRULY_RELIABLE_TSC_HONESTLY does imply one key feature which the code is missing today: on SMP VMs, the calibration of kvmclock needs to be done only once, and the clock can then be used for all VCPUs. That, I think, stops Glauber's bug from appearing on the server side.

That's the plan.


--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux