Hi, This proposal is for a mechanism to set the new MSR IA32_ENERGY_PERF_BIAS_MSR. This is a new hardware feature. The MSR effects overall power/performance. It gives a hint to the processor & package for desired power/performance characteristics. It is related to p-states and c-states (and may effect these features), but this feature can have other socket/system-level effects as well. The programmers guides do not go into details what the other effects can be. :-(
On 11/05/09 05:15, minskey guo wrote: > Jedy Wang ??: >> Hi Li, >> >> As far as I know, gnome-power-manager has removed the support for >> changing governor which is the same as profile I think. I remember >> someone wrote a blog explaining the reason but I can not find it now. I >> wonder why what makes us still need to implement this feature. > In linux world, there is ondemand governor in kernel. It sets cpu > freqency > according to cpu's current load. So, somebody consider that eveybody > should use that governor, and let CPUs finish their jobs asap and then > enter > into C states for power-saving. Comparing to P state, c-state does save > more power. That's why gnome removed it. Yes, a good p-state + c-state implementation is not easy to tune for more power savings. Running in lower p-states when a CPU is busy burns more power due to shorter time in deeper C-states. Entering deeper C-states too aggressively also burns more power (on both an idle and busy system) due to unnecessary wakeup latency. ;-) Without knowing the details, it seems likely that the gnome-power-manager was removed because setting it made worse decisions than a runtime prediction. Solaris currently has mechanisms to turn P-state and deeper C-state support on/off. A requirement is that the Energy Perf Bias MSR can be set on systems not running a GUI. We would like to support a possible future Gnome interface to set this MSR if/when it exists. The proposal provides a mechanism that works on systems without Gnome. > but, someone doesn't care power-saving, when comparing it to other > factors. For example, if you are plagued by the noise of CPU fan, and > expect quiet it then you can lower cpu frequency, which results in > lower heat, and then fan can be stopped. > > personally, I vote +1 for this project if I could vote, but I don't like > the names of "perf-bias" etc :) > > > Besides, can somebody tell me where IA32_ENERGY_PERF_BIAS_MSR > comes ? Is it a part of IPS feature ? Intel's Software Developer's Manuals 2A describes CPUID detection of IA32_ENERGY_PERF_BIAS_MSR and volume 3A describes the MSR. http://www.intel.com/products/processor/manuals/ Sorry, I do not know what IPS stands for? Regards, Bill > -minskey > > > >> I remember why already support 2 profile through gnome-power-manager on >> Solaris. What's the difference between them? >> >> I do not understand the exact meaning perf-bias, balanced and power-bias >> either. Does not perf-bias means the cpu frequency will be always at the >> highest level? >> >> Regards, >> >> Jedy >> On Wed, 2009-11-04 at 08:47 +0800, Li, Aubrey wrote: >> >>> Hi, >>> >>> When we enable intel energy performance bias feature, we found the >>> power >>> profile implementation is necessary. Here I did a draft for cpu >>> level power policy. >>> http://cr.opensolaris.org/~aubrey/cpu_power_policy_v1/ >>> >>> The proposal added a new keyword to /etc/power.conf >>> "cpu-power-policy", >>> And we have 4 options for this new keyword: >>> 1) perf-bias >>> 2) balanced >>> 3) power-bias >>> 4) default, the same as perf-bias. >>> >>> /etc/power.conf accepts the user input and passes the prefered policy >>> to the kernel thru ioctl. Then pm_ioctl calls the callback to walk a >>> cpu >>> power policy list. Every cpu pm feature which wants to be adjusted by >>> this option and verified to be supported will register its callback >>> function >>> to the list, so that it can be called and adjusted by pmconfig. >>> -------------------------------------------------------- >>> /etc/power.conf >>> | >>> pm_ioctl(cpu_power_policy, policy) >>> | >>> cpu_power_policy_callb (policy) >>> | >>> ----> registered pm feature callback 1 (ENERGY_PERF_BIAS) >>> | >>> ----> registered pm feature callback 2 >>> ... >>> --------------------------------------------------------- >>> Currently, only energy_perf_bias feature is registered, because my >>> intention is >>> to support adjusting energy_perf_bias MSR without reboot. I guess we >>> probably >>> can add p/t/c-state support later. When we add p/t/c-state support, >>> my quick thought is, this option will override "cpupm" and >>> "cpu-deep-idle" setting. >>> >>> Welcome your any comments and suggestions. >>> >>> Thanks, >>> -Aubrey >>> _______________________________________________ >>> pm-discuss mailing list >>> pm-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/pm-discuss >>> >> >> >> _______________________________________________ >> pm-discuss mailing list >> pm-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/pm-discuss >> >> > > _______________________________________________ > pm-discuss mailing list > pm-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/pm-discuss
