On Monday, June 03, 2013 12:25:02 PM Viresh Kumar wrote: > Sent half written mail.. sorry.. will continue from where I left. > > On 3 June 2013 12:21, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > > > So, obviously the calculations aren't the same.. > > Now, this is how I understood these two different variables: > - cpuinfo.max_freq: maximum frequency (in kHz) which is > supported by this CPU > - policy->max: Maximum frequency forced by user or governor > > When somebody sets policy->max, he expects cpufreq core to > use the range between min and max as the slope cpufreq core > has and adjust its frequencies accordingly.. > > Don't know if I am right or wrong :( The reality is that the set of frequencies to use is constant and changing policy->max doesn't change that set. There are just fewer frequencies the governor can choose from if policy->max is below cpuinfo.max_freq. The question is if we want policy->max to re-scale them effectively (i.e. to change weights so that the maximum load maps to the highest frequency available at the moment) or if we want policy->max to work as a cap (i.e. to map all loads above certain value to the maximum frequency available at the moment, so that the criteria for selecting the lower frequencies don't change). In my opinion the second option is better, because it means "OK, we can't use some high frequencies, but let's not hurt performance for the loads that wouldn't require them anyway". Otherwise, we'll effectively throttle all loads and that not only causes performance to drop, but also causes more energy to be used overall. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
