Allow Intel platforms to declare unsynchronized TSC to kernel
in [Kernel]
|
Prev: hid: add experimental access to PicoLCD device's EEPROM and FLASH
Next: arch/arm: Use set_cpus_allowed_ptr
From: Hidetoshi Seto on 29 Mar 2010 05:50 (2010/03/29 16:46), Andi Kleen wrote: > Andi Kleen <andi(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |