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>
>> ----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?
>
> _______________________________________________
> tesla-dev mailing list
> tesla-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
>
