Ignacio Marambio Catán wrote: >> Currently, there is no way to force a processor to a lower frequency. A >> feature we'll be adding to Solaris soon. >> >> As for what determining what frequencies your processors are running at, >> you can find that out from the cpu_info kstat. >> > isnt there any mdb hack we could use? from the code i read not long > ago it seeems like everything is automatically done for us, we have no > way of setting the threshold in which it should scale down but i'm no > expert in kernel hacking so i might be wrong, according to the code > also there was an algorithm that prevented the processor to scale up > fast but that doesnt seem to be working here > from dmesg
Well, there is an mdb hack (enable cpudrv_direct_pm) along with a couple of ioctl(2) calls (PM_DIRECT_PM and PM_SET_CURRENT_POWER) that could give you direct control over the frequency. I'm not convinced you really want to go there though as I think you are misreading the messages from dmesg. The messages you've listed are printed to the system log whenever the maximum power level changes. These maximums are set outside the scope of Solaris by ACPI (and Solaris just complies with the request). All setting a new maximum means is that your processor cannot run at a frequency any higher than the new max power frequency. It does not mean that you processor is running at the new maximum frequency. So even when you processor has a new max power frequency of 1833 MHz, it could still be running at 1000 MHz. You'll need to use cpu_info (and possibly dtrace) if you want to know what frequency your processor is currently running at. If you're really interested in what these maximum power frequencies mean, then read up on _PDC and PDC change notifications in the ACPI specification. I believe these change requests are normally received for thermal reasons and I've noticed they occur frequently when booting the system. In any case, we are aware that our CPU power management policies need improving and we're working on it. You might be interested in joining the Tesla project to keep abreast of what is going on with power management in Solaris. Mark > Nov 25 20:09:37 saturn cpudrv: [ID 495817 kern.info] NOTICE: > cpudrv_pm_set_topspeed: instance 0: has new max power of 1000 MHz > Nov 25 20:09:37 saturn cpudrv: [ID 495817 kern.info] NOTICE: > cpudrv_pm_set_topspeed: instance 1: has new max power of 1000 MHz > Nov 25 20:09:37 saturn cpudrv: [ID 495817 kern.info] NOTICE: > cpudrv_pm_set_topspeed: instance 0: has new max power of 1000 MHz > Nov 25 20:09:37 saturn cpudrv: [ID 495817 kern.info] NOTICE: > cpudrv_pm_set_topspeed: instance 1: has new max power of 1000 MHz > Nov 25 20:09:53 saturn cpudrv: [ID 495817 kern.info] NOTICE: > cpudrv_pm_set_topspeed: instance 0: has new max power of 1833 MHz > Nov 25 20:09:53 saturn cpudrv: [ID 495817 kern.info] NOTICE: > cpudrv_pm_set_topspeed: instance 1: has new max power of 1833 MHz > Nov 25 20:09:53 saturn cpudrv: [ID 495817 kern.info] NOTICE: > cpudrv_pm_set_topspeed: instance 0: has new max power of 1833 MHz > Nov 25 20:09:53 saturn cpudrv: [ID 495817 kern.info] NOTICE: > cpudrv_pm_set_topspeed: instance 1: has new max power of 1833 MHz > > it also seems a bit biased into using only either the highest or the > lowest available frequency > > [EMAIL PROTECTED]:~$ kstat -m cpu_info -s supported_frequencies_Hz > module: cpu_info instance: 0 > name: cpu_info0 class: misc > supported_frequencies_Hz 1000000000:1333000000:1833000000 > > module: cpu_info instance: 1 > name: cpu_info1 class: misc > supported_frequencies_Hz 1000000000:1333000000:1833000000 > > > nacho _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
