julia harper wrote: > >Maybe this was already discussed... > >With regard to (future) impact on p-states and c-states -- if these are >being set by both >the OS and internal to the chip, which would win? I assume it would be >the lower power >state. Or would the OS settings simply be ignored? If the OS is >enforcing p-state caps >as instructed by PPC, is it possible that the chip could internally >apply a p-state >outside the allowed range without the OSes knowledge? > >-- jdh
Let's assume that all the CPUs always receive the same PPC number. I think the answer is no. The chip can't jump out of the range OS enforced. Similarly, the processor can't enter ACPI_C3 if there is a _CST change to throttle the idle state at ACPI_C2. Thanks, -Aubrey > > > >julia harper wrote: >> >> Would the cpu_pm_policy be treated as essentially a cap on the >register >> setting? That is, if the cpu_pm_policy setting maps to an MSR >setting >> of 9, does this mean the OS would then only dynamically choose MSR >> values between 9-15? >> >> -- jdh >> >> >> Bill Holler wrote: >>> Hi, >>> >>> I forgot to mention that cpu_pm_policy is just a policy. >>> There is no guaranty it maps to a specific MSR or hardware >>> implementation. >>> >>> For example Solaris could be dynamically setting the >>> ENERGY_PERFORMANCE_BIAS register to different >>> settings depending on things such as system-load, the >>> priority of the application being scheduled, a power policy >>> of the application, or power policy of the zone. >>> >>> Regards, >>> Bill >>> >>> >>> On 03/03/10 16:21, Bill Holler wrote: >>>> +1. >>>> >>>> Hi Aubrey, >>>> >>>> I also think it is time to move forward with this proposal. >>>> Generally we want the system to work best "out of the box" >>>> with no tuning. On the other hand, vendors will keep >>>> improving products with new features, and there will >>>> always be some specific applications were custom settings >>>> may be better. I feel this proposal supports innovation and >>>> application specific customization in line with the >>>> OpenSolaris community goals. >>>> >>>> This proposal applies to all types of CPUs. It uses >>>> "cpu_pm_policy" instead of for example mentioning a >>>> specific CPU's MSR. ;-) This proposal will be useful >>>> with other CPUs if/when they have hardware mechanisms >>>> for tuning power / performance. >>>> >>>> >>>> In the arc case we want to mention that there could >>>> be a policy conflict between this component setting and >>>> a system-power-policy, external Power Caping, etc. >>>> Generally we want users to use the default or a higher >>>> level policy such as the system power policy. >>>> Unfortunately the system power policy may not be >>>> fine-grain or diverse enough for some applications to >>>> specify cpu power policy. In that case cpu_pm_policy >>>> will be useful. My thought is: the user must really know >>>> what they want if they specify a component policy >>>> such as cpu_pm_policy instead of just using the >>>> system power policy. For that reason I feel cpu_pm_policy >>>> should override the system-power-policy at the cpupm level. >>>> >>>> Power Caping is different. Power Capping is an external >>>> policy. It is currently "owned" by the SP external to the >>>> OS. Power Caping should override a local cpu_pm_policy. >>>> >>>> >>>> Implementation comments: >>>> IMHO mcpu_pm_policy pointer should be in the >>>> mcpu_pm_mach_state structure instead of in the machcpu. >>>> We may want to allow the user to specify a number >>>> instead of just Perf, Balanced, Power, Default? >>>> >>>> Regards, >>>> Bill >>>> >>>> >>>> On 02/20/10 18:43, Li, Aubrey wrote: >>>>> Hi Bill, >>>>> >>>>> I think it's time to continue this proposal, since b134 is closed >>>>> and the >>>>> build is not limited now. power/perf bias setting is a start point >>>>> for future power related work, I'll prepare a PSARC file for the >new >>>>> option if >>>>> this is acceptable. No is also a good answer with good reason. >>>>> >>>>> Thanks, >>>>> -Aubrey >>>>> >>>>> >>>>>> 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 >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> _______________________________________________ >>> tesla-dev mailing list >>> tesla-dev at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/tesla-dev >> > >-- > >--------------------- > Julia Harper, julia.harper at sun.com > >_______________________________________________ >pm-discuss mailing list >pm-discuss at opensolaris.org >http://mail.opensolaris.org/mailman/listinfo/pm-discuss
