Li, Aubrey wrote: > On Saturday, December 01, 2007 4:01 AM, Mark.Haywood at Sun.COM wrote: > >> Mark Haywood wrote: >>> Eric Saxe wrote: >>>> Eric Saxe wrote: >>>>> Li, Aubrey wrote: >>>>>> C-state driver will let the processor go into deeper c-state. >>>>>> >>>>> I was thinking would use the existing mwait code path to bring the >>>>> processor into the deeper c-states? >>>>> ...or are you suggesting that the c-state driver would contain >>>>> code that is invoked out of that path? >>>>> >>>> Sorry. In case you can't parse the above, let me try again. ;) >>>> >>>> I was thinking we would use the existing mwait code path to bring >>>> the processor into the deeper c-states. >>>> Are you suggesting that the c-state driver would contain the code >>>> that could be invoked out of that path?... >>>> or something else? >>> I was wondering what we were going to do here too. Do the deeper >>> c-states tend to be vendor specific mechanisms? If so, then I think >>> we might want this support in a separate driver that can be accessed >>> via something like layered ioctls? This is what I was thinking of >>> doing with the reworked p-state support. >> BTW, I don't know how expensive this kind of mechanism might be. > > I think the deeper c-states shouldn't be vendor specific. > As long as: > 1) the processor supports different power saving mode when it's in idle > 2) the platform supports ACPI spec.
Do we know if 2) is true. What I mean is that ACPI defines how to do P-state transitions, but SpeedStep and PowerNow! (particularly the Opteron type) are pretty different to implement. Is it unlikely that there will be Vendor specific requirements for C-state support from different vendors? > As for how expensive, I think > 1)the policy is cheap. > 2) And the transition, C2 is no more than C1. C3 and deeper will be > responsible for ensuring that the caches maintain coherency. > 3) And the timer/interrupts needs to be fixed. > Others needs to be further investigated, ;-) > > Thanks, > -Aubrey > > > > > >
