tesla-dev-bounces at opensolaris.org wrote:
> Mark Haywood wrote:
>> Li, Aubrey wrote:
>>
>>> Mark.Haywood at Sun.COM wrote:
>>>
>>>
>>>> Li, Aubrey wrote:
>>>>
>>>>> Bill.Holler wrote:
>>>>>
>>>>>
>>>>>>>> Eric and I have been talking about a policy to determine which
>>>>>>>> idle state to use. We know decision input will include:
>>>>>>>> 1. time until next cyclic fires on this cpu.
>>>>>>>> 2. dispatcher hint. The power-aware dispatcher will try to
>>>>>>>> move threads off whole cpu chips based on system idleness.
>>>>>>>> 3. User specified policy.
>>>>>>>> 4. C-state round trip latency.
>>>>>>>> cpu_acpi_idle() could call an idle policy function to
>>>>>>>> determine with C state to attempt.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> deeper C-state needs TSC be fixed. What's the status of it and
>>>>>>> HPET timer?
>>>>>>>
>>>>>>>
>>>>>> We need systems to test TSC fixup code. There are several
>>>>>> strategies we want to test. 1. re-sync a cpu's TSC with a
>>>>>> master using x-call,
>>>>>> 2. keep per-thread or per-cpu "last TST" to fixup when a thread
>>>>>> reads an older TST (yuck). The HPET timer could be used to
>>>>>> re-initialize TSC when all cpus have returned from a deep
>>>>>> C-state. I am starting work on this now. I will start testing
>>>>>> by injecting TSC clobbers during
>>>>>> C1 idle wakeup on a Core 2 Duo until new hardware arrives.
>>>>>>
>>>>>>
>>>>> IA Processor families increment the TSC differently:
>>>>> --> for Pentium M processors ( family [06H], models[09H, 0DH]
>>>>> for Pentium 4 processors, Intel Xeon processors ( family
>>>>> [0FH], models [ 00H, 01H, or 02H]) and for P6 family
>>>>> processors: TSC increments with every internal processor
>>>>> clock cycle.
>>>>>
>>>>> That means Speedstep may impact the TSC on these kinds of CPU.
>>>>> For others TSC increments at a constant rate, it should be ok.
>>>>>
>>>>> So, did we encountered any problem so far when SpeedStep enabled?
>>>>>
>>>> No, because Solaris only supports SpeedStep on processors
>>>> belonging to familoes 0xF with models >= 0x3 and familie 0x6 with
>>>> models >= 0xE.
>>>>
>>>>
>>> OK, so will the limitation be removed if TSC issue is fixed?
>>>
> <babbling>
> We are talking about two different TSC symptoms:
> 1. The TSC stops incrementing or resets to 0 when a processor is in
> an idle state such as C3.
> 2. TSC increments at different rates depending on P-state.
> TSC possibly increments at an indeterminate rate during P-state
> transition.
>
> At first glance it would appear C-states & TSC is independent of the
> Speedstep|P-state & TSC issue?
>
> IIRC deeper C-states have higher latency than P-state
> transitions? If so,
> we may be more willing to accept higher latency TSC "fixup" solutions
> with deep C-states. </babbling>
>
Yes, C-states & TSC is independent of the EIST & TSC issue.
One is reset while the other is changed.
As for the latency, C2 shouldn't be higher than P-state transition.
And C3 should be much higher than it.
But the latency depends on the platform. BIOS and ACPI will tell us the
value of it.
Things are getting better. We have the coming processor on which TSC
issued is fixed of both EIST and deeper C-state case.
>>> ----snip----
>>> family = cpuid_getfamily(CPU);
>>> model = cpuid_getmodel(CPU);
>>> if (!((family == 0xf && model >= 0x3) ||
>>> (family == 0x6 && model >= 0xe))) {
>>> ESSDEBUG(("Variant TSC not supported.\n"));
>>> return (ESS_RET_NO_PM);
>>> }
>>> ----snip----
>>>
>>
>> I supposed that depends a lot on the robustness of how the TSC issue
>> is fixed. However, I was under the impression that the TSC wouldn't
>> be an issue with regard to P-states going forward. That is, recent
>> and future Intel processors are and will be P-state TSC invariant?
>> So, removing this restriction would only help support legacy
>> processors?
>>
Yes, TSC issue should be fixed in the future processors.
As for the legacy processors, if TSC related code is fixed in the
kernel,
we may have a try.
Thanks,
-Aubrey
