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