okay, thanks for the info, that sounds good. Margot, could you please add me to the ARC case interested list? Or please keep me updated the progress.
Thanks, -Aubrey Garrett D'Amore wrote: > >On 04/ 1/10 08:28 AM, Margot Hackett Miller wrote: >> We are in the process now of moving what's in power.conf >> to SMF. I will be filing an ARC case in a few weeks for it. > >Then I recommend doing that case *before* introducing another power.conf >tunable. > > - Garrett >> >> Margot >> >> >> On 03/31/10 10:29 PM, Garrett D'Amore wrote: >>> On 03/31/10 09:09 PM, Randy Fishel wrote: >>>> >>>> This might be a bit contentious, as there not only is effort to >>>> migrate the configuration to SMF, there is a consideration to define >>>> something similar to system-pm-policy. On the other hand, there >also >>>> is lacking architecture and there doesn't seem to be much momentum >in >>>> providing it. >>> >>> Strongly concur on this. This (and other PM management settings) >>> belongs in SMF now. >>> >>> This will probably be derailed if you try to integrate this change >>> without doing it via SMF. >>> >>> - Garrett >>>> I am also leaving for vacation on Friday morning. I will take a >>>> printout with me in hopes of maybe reviewing it over the next week. >>>> It may also give others the opportunity to see how this might fit >into >>>> the "new" architecture. >>>> >>>> Cheers! >>>> >>>> ---- Randy >>>> >>>> On Thu, 1 Apr 2010, Li, Aubrey wrote: >>>> >>>>> Just wanna move forward for this work, here is a PSARC onepager, >>>>> Any inputs >>>>> are really appreciated! >>>>> >>>>> Thanks, >>>>> -Aubrey >>>>> >>>>> ======== system-pm-policy_onepager_v1.txt >>>>> ================================= >>>>> Template Version: @(#)onepager.txt 1.35 07/11/07 SMI >>>>> >>>>> 1. Introduction >>>>> 1.1. Project/Component Working Name: >>>>> system-pm-policy keyword >>>>> >>>>> 1.2. Name of Document Author/Supplier: >>>>> Author: Aubrey Li<[email protected]> >>>>> >>>>> 1.3. Date of This Document: >>>>> April 28 , 2010 >>>>> >>>>> 2. Project Summary >>>>> 2.1. Project Description: >>>>> Solaris support for the system-pm-policy keyword in >>>>> power.conf(4). >>>>> A mechanism is desired to set system wide power >>>>> performance bias. >>>>> >>>>> 2.2. Risks and Assumptions: >>>>> Very few customers will use this keyword. Most customers >>>>> will desire >>>>> power performance balanced policy to be the default. >>>>> >>>>> 4. Technical Description: >>>>> 4.1. Details: >>>>> >>>>> pmconfig(1M) parses /etc/power.conf, if the >>>>> system-pm-policy keword >>>>> is in power.conf(4), it passes the user preferred policy >>>>> to the kernel >>>>> thru pm_ioctl by the command PM_SET_SYSTEM_POLICY. >>>>> pm_ioctl() then >>>>> calls pm_set_system_policy() to set the global policy >>>>> variable and >>>>> calls the power managable modules to pass the policy down. >>>>> >>>>> Currently pm_set_system_policy() only set the CPU power >>>>> management >>>>> policy, and could set memory and other devices power >>>>> management policy >>>>> in future. CPU pm policy setting is machine specific. >>>>> >>>>> CPU has a few power management features, like C-state, >>>>> P-state, energy >>>>> performance bias etc. Every CPU pm feature which wants to >>>>> inherit the >>>>> system-pm-policy will register its callback function to a >>>>> list, when >>>>> pmconfig passes the policy to the kernel, the kernel will >>>>> walk the list >>>>> to call the callback function and hence set the user >>>>> perferred policy >>>>> to the different modules. >>>>> >>>>> /etc/power.conf may have [system-pm-policy<value>] >>>>> | >>>>> v >>>>> pmconfig >>>>> | >>>>> v >>>>> pm_ioctl(PM_SET_SYSTEM_POLICY, policy) >>>>> | >>>>> v >>>>> pm_set_system_policy(policy) >>>>> | >>>>> ----> CPU pm policy callback >>>>> | | >>>>> | ----> registered CPU pm feature 1 >>>>> callback(ENERGY_PERF_BIAS) >>>>> | | >>>>> | ----> ... >>>>> | >>>>> ----> Memory pm policy callback in future >>>>> | >>>>> ----> ... >>>>> >>>>> >>>>> Power performance balanced policy will be set by default, >>>>> this keeps the >>>>> current out-of-box setting unchanged. The system which has >>>>> extreme >>>>> performance requirements could disable the power >>>>> management features by >>>>> performance bias setting. If laptop runs on a battery, or >>>>> the system in >>>>> the low utilization prefers power than performance, >>>>> system-pm-policy could >>>>> be set to power bias and save more power, this could lead >>>>> to the lowest >>>>> CPU clock and always deepest idle state. >>>>> >>>>> Different power manageable devices could inherit the >>>>> system wide policy >>>>> completely, or they can maintain a specific pm policy >>>>> themselves but the >>>>> system wide policy must be the biggest weight coefficient >>>>> to their own >>>>> mechanism. >>>>> >>>>> >>>>> 4.2. Bug/RFE Number(s): xxxxxxx >>>>> >>>>> 4.5. Interfaces: >>>>> This project will import these existing interfaces. >>>>> Interface stability will be "committed". >>>>> >>>>> Import: >>>>> power.conf(4) (PSARC/1992/202) >>>>> pmconfig(1m) >>>>> >>>>> Export: >>>>> system-pm-policy >>>>> >>>>> system-pm-policy keyword. >>>>> A system-pm-policy entry can be added to power.conf(4) to >>>>> set the system >>>>> wide power policy. If this entry is present and set to >>>>> default or it is >>>>> not present then the default balanced policy will be used, >>>>> this keeps the >>>>> current behavior unchanged. The other options will tune >>>>> the policy to power >>>>> bias or performance bias. >>>>> >>>>> power.conf(4) man page addition: >>>>> >>>>> a system-pm-policy may be used to set system wide power >>>>> policy. The format >>>>> of the system-pm-policy entry is system-pm-policy policy. >>>>> >>>>> Acceptable policy values are: >>>>> >>>>> default Power performance balanced policy. >>>>> >>>>> perf-bias The system drives to maximum performance at any >>>>> energy cost. >>>>> >>>>> balanced Balanced performance vs. power and energy >>>>> >>>>> power-bias Max energy efficient. >>>>> >>>>> absent If the system-pm-policy keyword is absent from >>>>> power.conf(4), >>>>> the behavior is the same as the default case. >>>>> >>>>> 4.6. Doc Impact: >>>>> power.conf man page. See above. >>>>> >>>>> 4.7. Admin/Config Impact: >>>>> Administrators of systems can use this option to match the >>>>> different power >>>>> performance requirement. >>>>> >>>>> 4.8. HA Impact: None. >>>>> >>>>> 4.9. I18N/L10N Impact: No. >>>>> >>>>> 4.10. Packaging& Delivery: >>>>> This change will be delivered as part of the Deep C-State >>>>> RFE. >>>>> These changes will be made at the same time: >>>>> kernel package >>>>> power.conf package >>>>> pmconfig package >>>>> >>>>> 4.11. Security Impact: None. >>>>> >>>>> 4.12. Dependencies: power.conf, pmconfig(1M) >>>>> >>>>> 6. Resources and Schedule: >>>>> 6.1. Projected Availability: April 2010 >>>>> >>>>> 6.4. Product Approval Committee requested information: >>>>> 6.4.1. Consolidation C-team Name: >>>>> ON >>>>> 6.5. ARC review type: FastTrack >>>>> 6.6. ARC Exposure: open >>>>> >>>>> 7. Prototype Availability: >>>>> 7.1. Prototype Availability: >>>>> Prototype available on OpenSolaris in April 2010. >>>>> >======================================================================== >=========== >>>>> >>>>> >>>>> Li, Aubrey wrote: >>>>>> Hi Bill, >>>>>> >>>>>> Here I made a change to propose system-wide policy support. >>>>>> http://cr.opensolaris.org/~aubrey/sys_pm_policy_v1/ >>>>>> The user profile from /etc/power.conf is still passed to the >kernel >>>>>> thru pm_ioctl, then call pm_set_system_policy(). Currently there >>>>>> is only >>>>>> cpu pm policy setting there, if memory/other devices need a bias >>>>>> as well, >>>>>> they can also be added to that function. >>>>>> cpu pm policy related implementation has minor change against last >>>>>> webrev, >>>>>> mcpu_pm_policy pointer has been moved from machcpu to >>>>>> mcpu_pm_mach_state >>>>>> structure according to your suggestion. >>>>>> >>>>>> Any comments and suggestions are highly appreciated. >>>>>> >>>>>> Thanks, >>>>>> -Aubrey >>>>>> >>>>>> Li, Aubrey wrote: >>>>>>> It looks like memory PM need such a bias as well. So I'd like to >>>>>>> change >>>>>>> the proposal to use the keyword "sys-pm-policy" instead. The >>>>>>> mechanism >>>>>>> will use the existing callb implementation to pass the user >>>>>>> policy from >>>>>>> /etc/power.conf to the kernel and walk the module registered list >to >>>>>>> call >>>>>>> module hook function to set the pm policy individually. >>>>>>> >>>>>>> I'm not sure if any other device driver need or be happy with >this >>>>>>> proposal. >>>>>>> It would be great if the device driver developer can share some >>>>>> thoughts >>>>>>> here. >>>>>>> >>>>>>> Thanks, >>>>>>> -Aubrey >>>>>>> >>>>>>> Julia.Harper wrote: >>>>>>>> I assume that this knob (profile) when turned way down would >>>>>>>> basically >>>>>>>> put the >>>>>>>> system into "power savings" mode -- where the set of power >>>>>>>> states is >>>>>>>> restricted. >>>>>>>> That is, no matter how long the utilization level demands more >>>>>>>> power, >>>>>>>> the >>>>>>>> highest power states (for the cpus, memory, whatever) will never >be >>>>>>>> entered. We >>>>>>>> should probably use terminology that makes this clear. >>>>>>>> >>>>>>>> -- jdh >>>>>>>> >>>>>>>> >>>>>>>> Liu, Jiang wrote: >>>>>>>>> I prefer the solution to introduce a global power profile for >all >>>>>>>> devices. Currently >>>>>>>>> we need such a profile for CPUPM. In future when supporting >memory >>>>>>>> power >>>>>>>>> management, we may need a similiar profile for memory PM. And >user >>>>>>>> won't >>>>>>>>> like two variables/profiles for the same objective. >>>>>>>>> >>>>>>>>> Li, Aubrey<> wrote: >>>>>>>>>> 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. >>>>>>>>>> Yes, I would like to propose a new option for CPU power >>>>>>>>>> management >>>>>>>>>> policy. This policy is a CPU bias between performance and >power, >>>>>> the >>>>>>>>>> future CPU power management enhancement work can be based on >this >>>>>>>>>> policy. - the default policy should keep the current "out of >the >>>>>>> box" >>>>>>>>>> behavior unchanged, we'll try to save more power without >>>>>> performance >>>>>>>>>> hurt. >>>>>>>>>> - there will be more power management futures coming on the >>>>>>>>>> future >>>>>>>>>> processor, like ENERGY_PERFORMANCE_BIAS, we can register these >>>>>>>>>> new >>>>>>>>>> futures under the policy framework, and offer a knob to the >>>>>>>>>> user to >>>>>>>>>> change these settings on the fly. >>>>>>>>>> - laptop users who want to prolong the battery life and less >heat >>>>>>> and >>>>>>>>>> smaller fan noise may want the system to work in some edge >>>>>> situation: >>>>>>>>>> for example, currently CPU can work in the highest clock if >cpupm >>>>>> is >>>>>>>>>> disabled, but no choice to let CPU always work in the lowest >>>>>>>>>> clock. >>>>>>>>>> Similarly, Always enter deepest c-state is another choice to >save >>>>>>>>>> more power. What's more, power aware dispatcher could be more >>>>>>>>>> flexible to pick up CPU and dispatch thread if there is a >policy >>>>>>>>>> indicator. - Some users doesn't care about power. Yes, we >already >>>>>>>>>> have the options to let them to set ENERGY_PERFORMANCE_BIAS to >be >>>>>>>>>> performance bias, to close c-state/p-state, and so on and so >>>>>>>>>> forth. >>>>>>>>>> But it's more friendly to the user to just change only one >>>>>>>>>> option. >>>>>>>>>> >>>>>>>>>> Here, the policy only focus on CPU. If you think we should >have a >>>>>>>>>> policy for the memory, for the devices, or we should have a >>>>>>>>>> system-wide policy, let's do this. cpu_pm_policy can be one >>>>>>>>>> part of >>>>>>>>>> system-wide policy. >>>>>>>>>> If nobody have thoughts on it, I'll continue to prepare a >PSARC >>>>>> file >>>>>>>>>> to add cpu_pm_policy keyword. >>>>>>>>>> >>>>>>>>>>> For example Solaris could be dynamically setting the >>>>>>>>>>> ENERGY_PERFORMANCE_BIAS register to different settings >depending >>>>>> on >>>>>>>>>>> things such as system-load, >>>>>>>>>> Yes, such of these settings can be dynamically changed if we >see >>>>>> the >>>>>>>>>> benefit. >>>>>>>>>> >>>>>>>>>>> the priority of the application being scheduled, a power >>>>>>>>>>> policy of >>>>>>>>>>> the application, >>>>>>>>>> Making the thread power aware need another bunch of interfaces >I >>>>>>>>>> think. For example, cmt_balance() can choose the different >>>>>> processor >>>>>>>>>> group according to the perf/power bias of the thread. >>>>>>>>>> >>>>>>>>>>> or power policy of the zone. >>>>>>>>>> Zone policy is an interesting topic. Different zone could have >>>>>>>>>> different CPU resource, or can share the global CPU resource, >>>>>>>>>> different zone could have different power policy, or they can >>>>>>> inherit >>>>>>>>>> the global cpu_pm_policy setting. The virtual container could >>>>>>>>>> have >>>>>>>>>> many, but the hardware resource is unique. I think this can be >>>>>>>>>> enhanced in the zone management, which will not be covered in >my >>>>>>>>>> proposal, :) >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> -Aubrey >>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>> http://mail.opensolaris.org/mailman/listinfo/pm- >discuss >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> pm-discuss mailing list >>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>> http://mail.opensolaris.org/mailman/listinfo/pm-discuss >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> pm-discuss mailing list >>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>> http://mail.opensolaris.org/mailman/listinfo/pm-discuss >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> pm-discuss mailing list >>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>> http://mail.opensolaris.org/mailman/listinfo/pm-discuss >>>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> pm-discuss mailing list >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> http://mail.opensolaris.org/mailman/listinfo/pm-discuss >>>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> pm-discuss mailing list >>>>>>>>>>>> [email protected] >>>>>>>>>>>> http://mail.opensolaris.org/mailman/listinfo/pm-discuss >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> pm-discuss mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> http://mail.opensolaris.org/mailman/listinfo/pm-discuss >>>>>>>>>> _______________________________________________ >>>>>>>>>> tesla-dev mailing list >>>>>>>>>> [email protected] >>>>>>>>>> http://mail.opensolaris.org/mailman/listinfo/tesla-dev >>>>>>>>> Liu Jiang (Gerry) >>>>>>>>> OpenSolaris, OTC, SSG, Intel >>>>>>>>> _______________________________________________ >>>>>>>>> pm-discuss mailing list >>>>>>>>> [email protected] >>>>>>>>> http://mail.opensolaris.org/mailman/listinfo/pm-discuss >>>>>>>> -- >>>>>>>> >>>>>>>> --------------------- >>>>>>>> Julia Harper, [email protected] >>>>>>> _______________________________________________ >>>>>>> pm-discuss mailing list >>>>>>> [email protected] >>>>>>> http://mail.opensolaris.org/mailman/listinfo/pm-discuss >>>>>> _______________________________________________ >>>>>> pm-discuss mailing list >>>>>> [email protected] >>>>>> http://mail.opensolaris.org/mailman/listinfo/pm-discuss >>>> _______________________________________________ >>>> pm-discuss mailing list >>>> [email protected] >>>> http://mail.opensolaris.org/mailman/listinfo/pm-discuss >>> >>> _______________________________________________ >>> pm-discuss mailing list >>> [email protected] >>> http://mail.opensolaris.org/mailman/listinfo/pm-discuss >> > >_______________________________________________ >pm-discuss mailing list >[email protected] >http://mail.opensolaris.org/mailman/listinfo/pm-discuss _______________________________________________ pm-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pm-discuss
