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? >> 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
