Bill.Holler Wrote: > >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. :-(
The perf and power impact of this MSR is model specific. It's able to throttle turbo on WSM and probably help to do more hardware decision in future. For example, when the short interrupt storm is detected, it can demote CC6 request to CC3. > > >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. This is also model specific and depends on if the frequency and voltage and power are linear. That's true on latest processor but not on earlier processor. I'm not sure why gnome removed it, but seems not a good idea to me. Some users want max perf and others want longer battery life. > >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. Right, most of servers do not run gnome. I don't expect gnome support but it would be great if it will, :-) IMHO, we should use this global cpu power policy setting instead of "cpupm" and "cpu-deep-idle", this is more friendly to the user. The users just want more perf or more power, I think they don't care if the system support p/c-state at the same time. "cpupm" is a confusion only for p-state. we call "cpupm" before we have deep idle support. Actually cpu-deep-idle is also one part of cpu power management, :) > > >> 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? cough, cough, IPS is not a released feature and should not be discussed here, ;p Thanks, -Aubrey > >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 > >_______________________________________________ >pm-discuss mailing list >pm-discuss at opensolaris.org >http://mail.opensolaris.org/mailman/listinfo/pm-discuss
