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?
Regards,
-Aubrey
