Re: [PATCH] Allow Intel platforms to declare unsynchronized TSC to kernel

[Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>]

(2010/03/29 16:46), Andi Kleen wrote:
> Andi Kleen <andi@firstfloor.org> writes:
> 
>> Allow Intel platforms to declare unsynchronized TSC to kernel
>>
>> [This came out of a private discussion with Linus last week]
> 
> Ping?  Please review this patch.
> 
> -Andi

Does "constant" implicitly means "synchronized"?
IMHO the answer is no.

Following commit tells us that there could be
"constant-but-unsynchronized TSC":
 6c56ccecf05fafe100ab4ea94f6fccbf5ff00db7
> So, reenable TSC sync test even on constant and non-stop TSC systems.

Quote from the patch description of commit:
 40fb17152c50a69dc304dd632131c2f41281ce44
> Add support for CPUID_0x80000007_Bit8 on Intel CPUs as well. This bit means
> that the TSC is invariant with C/P/T states and always runs at constant
> frequency.
>
> With Intel CPUs, we have 3 classes
> * CPUs where TSC runs at constant rate and does not stop n C-states
> * CPUs where TSC runs at constant rate, but will stop in deep C-states
> * CPUs where TSC rate will vary based on P/T-states and TSC will stop in
>   deep C-states.

It looks like that "invariant" also means "constant."

I suppose your change is intended to allow newer platform to declare
"not invariant", instead of "not invariant but constant."
Humm, but how things change...?  Still newer platform cannot declare
one of 3 classes.  Which class is "never on newer platform"?
Or we need to have 4th new class? 

At least I think your patch description needs some update,
to get more comments without confusing reviewers.


Thanks,
H.Seto