On Wed, Jun 18, 2008 at 03:09:41PM -0500, Anthony Liguori wrote: > Marcelo Tosatti wrote: >> Avi, I don't think this causes such a huge performance regression. NOHZ >> makes the frequency of timer reads go down significantly. >> > > 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. Also, as mentioned earlier, large systems with clustered APIC have unstable TSC. 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). -- 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
