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. Mark
