Mark.Haywood at Sun.COM wrote: > I created the repository that we can use for the CPU power management > rework. You can clone it: > > $ hg clone ssh://your-login at hg.opensolaris.org/hg/tesla/cpupm-gate > > I'll update the Tesla project page with the necessary cpupm-gate > information.
Thanks for the work. From the patch, the framework looks good to me, ;-) > > I have some comments in-line below ... > > Li, Aubrey wrote: >> On Wednesday, November 28, 2007 5:32 AM, Mark.Haywood at Sun.COM wrote: >> We can discuss more details later, like speedstep feature, it's >> taken as a platform feature, not a processor feature, so it's not >> necessary to check it in the intel_cpupm_init(). >> > > I'm not really sure what you are saying here. Take a look at the patch > and see if what I've done makes sense in this regard. Remember that we > are not supporting SpeedStep on all processors (not even all Intel > processors). I mean, checking something like the bit CPUID_INTC_ECX_EST of CPUID is not necessary here. Even thought you know the processor supports speedstep feature, but BIOS doesn't give it out, You have to return failure later. Does this make sense? > >> Besides the initialization funtion, cpudrv_power()(and structure >> cpudrv_pm) is another point need to be considered. >> Currently it only care about speed, C-state and T-state should be >> included as well. >> > > Yes, I expect to be pulling the CPU driver apart. It's > currently common > code with the SPARC CPU driver. Given where we are headed, I > don't think > this makes sense. So, the cpudrv_pm structure (if it continues to be > called that) will change significantly. > > You believe that cpudrv_power (maybe this function needs to be > renamed) should care about T-states and C-states? Currently, this > function just handles P-state transitions. I'm not sure that it > should care about T-states and C-states. It depends on the policy. C-state policy may not be included in cpudrv_power(), but may be yes. > >> And the policy, they have the different behavior, don't they? > Sorry, which policies are you talking about? We currently only > have one > P-state policy (autopm behavior). We'll be adding more > policies as part > of this project though (e.g., ability to set CPUs to specific > frequency). Are these the policies that you are referring to? If so, > yes, I'm sure we'll be caching policy information in the driver > structure somehow. I mean the policy for C-state and T-state, they should have the different policy from P-state. P-state depends on the cpu utilization, C-state depends on the idle resident time, and T-states may depend on the cpu temperature. -Aubrey
