Aubrey Li wrote: > On 7/24/07, Mark Haywood <Mark.Haywood at sun.com> wrote: > >> Cyril Plisko wrote: >> >>> On 7/23/07, Mark Haywood <Mark.Haywood at sun.com> wrote: >>> >>> >>>> Aubrey Li wrote: >>>> >>>> >>>>> On 7/23/07, Cyril Plisko <cyril.plisko at mountall.com> wrote: >>>>> >>>>> >>>>>> On 7/23/07, Aubrey Li <aubreylee at gmail.com> wrote: >>>>>> >>>>>> >>>>>>> Hi list, >>>>>>> >>>>>>> >>>>>>> >>>>> I checked just now, between Build67 and hg tip revision 4700. There >>>>> are no big difference. >>>>> >>>>> >>>> Forgive my ignorance. What is the hg tip revision 4700? >>>> >>>> >>> ON consolidation at revision 4700, I guess. 4700 seems to be >>> the latest revision as of Jul 22. Build 67 was revision 4444. >>> >>> >> Thanks. I better get used to Mercurial. I downloaded the latest source >> and verified that revision 4700 does include the SpeedStep support. It's >> not enabled by default in Solaris. You have to enable it by editing >> power.conf(4) and adding the following entries: >> >> cpupm enable >> cpu-threshold 15s >> >> And then in order to inform the kernel of the new policy, you must run >> pmconfig(1M). >> Alternatively, you could use the /usr/dt/bin/dtpower GUI. >> >> As far as the comparison against Linux though, it makes no sense to >> enable CPU power management on Solaris if it wasn't enabled on Linux. >> >> > > Hi Mark - three questions for you, ;-) > > 1) Is there any existing interface to show current CPU frequency to > the userland? You know CPU frequency changes from time to time while > **psrinfo -vp** always shows a fixed frequency. > 'kstat cpu_info' has a field, current_clock_Hz, that should report the current CPU frequency. > 2) What doesn't cpu-threshold value mean? check and convert CPU > frequency if needed every 15 seconds? I doubt it. Because I add some > print points to the fun speedstep_pstate_transition(), and the log > told me it could be changed 5, 6 seconds. > It means that if a CPU is left idle for a period of cpu-threshold, then the CPU should transition from highest to lowest power level. For example, if the cpu-threshold is set to 60 seconds and the CPU supports 4 P-states and the CPU is "idle" for 60 seconds, then every 60/(4 -1) = 20 seconds then CPU will be lowered a P-state and after 60 seconds should be in it's lowest P-state.
Since the Solaris Power Management framework only scans once every 15 seconds, I'm not sure how to account for the transitions your're seeing every 5 to 6 seconds. I'll have to believe that it's because the framework or the ppm module transitioned through each of the P-states one at a time, rather than going from P-state 0 to P-state n directly. I'll have to look into that. Also, it is the case that the CPU can raise it's power level at any point. If the CPU driver determines that it is busy, then it can immediately request that it's power level be raised. So, it could be the case that you lowered a P-state and then the CPU became busy a few seconds later and raised it's P-state. > 3) I roughly take a look at the folder **cmd/power**, Does it include > all the power policy, including CPU power policy? > Well, it contains the code that parses power.conf(4) and issues ioctls to the pm driver which is used to communicate with the sunpm.o module in the kernel. The policy really resides in the kernel in the sunpm.o module. Mark
