Mark Haywood wrote: > David Vengerov wrote: > >> Yes, there are only several possible frequencies that can be chosen, >> but which one of them should be chosen? It is not optimal to keep >> stepping through them after a certain jump in the CPU utilization, >> and a jump between frequencies might be more appropriate. > > > A combination of user policy and utilization thresholds based on > frequency percentages would probably help make the decision. I think > it would require some experimentation and tools for measuring power > and performance to figure out our behavior.
If we trust the user to optimally set all parameters in the "incremental" policy, then our job is done. But in reality, how will the user know the optimal parameter values? They can only be obtained through experimentation for a particular workload, where the user will observing the performance number for that workload and the power consumed, will plug these numbers into its performance vs. power utility function (which can exist in the mental space only), and finally choose the policy that maximizes utility. And when the workload changes, the user will have to repeat this process from scratch. Well, we can help the user in this process by automating it and asking the user only to provide us with the utility function. > Maybe I've misunderstood you. The description of the HAL > SetCPUFreqPerformance method is "Sets the performance of the dynamic > scaling mechanism. This method summarizes and abstracts all the > different settings which can be taken for dynamic frequency > adjustments, like at which load to switch up frequency or how many > steps the mechanism should traverse until reaching the maximum > frequency. The higher the value, the more performance you get. > Respectively, the higher the value, the sooner and the more often the > frequency is switched up." > > So I read this as it's the method a user would use "to specify (or > choose from several options) a utility curve." I would say that the user would use its utility curve to set parameters of the "incremental" policy. > So, if I understood you earlier, then what you're suggesting > (different power vs performance options) is already accepted within > the community. I think it is accepted at the "lower" level of asking the user to set parameters of particular policies as opposed to the "higher" level of providing the pure utility curve and letting the system to optimize policy parameters for that curve. >> >> What kind of application feedback will available in Nevada? > > > Unfortunately, very little. The implementation mirrors what was done > for Solaris SPARC CPU power management. There is no direct feedback > from the CPU driver itself (other than some kstat output). All > application feedback would come via the Solaris Power Management > framework ioctls (many of which are undocumented and are not public). > Note that I did say, we have "a good start". There is much room for > improvement. Well, if we want to start with some internal experiments evaluating the potential benefit from using the application feedback, then the current ioctls are sufficient, right? David -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/tesla-dev/attachments/20070608/294de621/attachment.html>
