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?
> ----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?
