Re: [PATCH] cpufreq: ondemand: Change the calculation of target frequency

[Rafael J. Wysocki]

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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/