Marcelo Tosatti wrote:
On Wed, Jun 18, 2008 at 04:02:39PM -0500, Anthony Liguori wrote:
Have we yet determined why the TSC is so unstable in the first place?
In theory, it should be relatively stable on single-node Intel and
Barcelona chips.
If the host enters C2/C3, or changes CPU frequency, it becomes
unreliable as a clocksource and there's no guarantee the guest will
detect that.
On Intel, the TSC should be fixed-frequency for basically all shipping
processors supporting VT. Starting with 10h (Barcelona), I believe AMD
also has a fixed frequency TSC.
But still stops ticking in C2/C3 state, I suppose?
I don't know for sure but the TSC is not tied to the CPU clock so I
would be surprised if it did. I think that that would defeat the
utility of a fixed-frequency TSC.
Regards,
Anthony Liguori
Also, as mentioned earlier, large systems with clustered APIC have
unstable TSC.
Right, that's why I qualified with single-node.
We _could_ hook this fake-C2-state thing to the host TSC reliability:
1) Hook into Linux's mark_tsc_unstable().
2) On migration check if the destination host is using the TSC, if not,
force a faked-C2-state.
Problem with 2) is that not all guests honour the ACPI _CST package
notification (which would change C2's latency time from an unusable
value to something usable). And now I don't think assuming the _CST
notification to work is a good thing (after we found out that for ex.
Ubuntu 7.10 kernel ignores it).
I think that for hosts with a known unstable TSC, we should do something
like this. But I also think we have a bug with TSC synchronization for
AMD although I don't at all know what the source of it is.
Chris has some patches around, I don't remember the details either.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
