Re: [patch 0/7] force the TSC unreliable by reporting C2 state

[Marcelo Tosatti <mtosatti@redhat.com>]

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).