On 12/17/2010 07:43 PM, Zachary Amsden wrote:
On 12/15/2010 10:16 AM, Julien Desfossez wrote:
Hi,
I'm currently working with the kvm clocksource and I'm wondering if
we could implement the vread function for this clock source when we
are running on a host with constant_tsc.
If I understand correctly the hv_clock structure is per_cpu because
of the eventual frequency changes, but in the case of constant_tsc
(and after validation that the TSC is synchronized across all the
cores) I think we could have a working vread function.
In case of migration, could we have a fallback in case we detect we
end up on a CPU without constant_tsc ?
Any advice/explanation would be greatly appreciated !
It's a bit more complex than that. In addition to the problem you
mention with migration, even if the TSC is synchronized, the kvmclock
still is not, even with constant_tsc. There is measurement error in
between reading the TSC and computing the per_cpu hv_clock offset
which varies between CPUs.
What about using rdtscp?
We could also disable kvmclock if constant_tsc and migration is not
desired, or if constant_tsc and the new tsc multiplier on bulldozers is
available on all machines in the migration cluster.
--
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
