On Friday, February 22, 2013 11:27:09 AM Viresh Kumar wrote: > On Fri, Feb 22, 2013 at 7:26 AM, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > > On 21 February 2013 23:09, Stratos Karafotis <stratosk@xxxxxxxxxxxx> wrote: > > >> Instead of checking only the absolute value of CPU load_freq to increase > >> frequency, we detect forthcoming CPU load rise and increase frequency > >> earlier. > >> > >> Every sampling rate, we calculate the gradient of load_freq. If it is > >> too steep we assume that the load most probably will go over > >> up_threshold in next iteration(s) and we increase frequency immediately. > >> > >> New tuners are introduced: > >> - early_demand: to enable this functionality (disabled by default). > >> - grad_up_threshold: over this gradient of load we will increase > >> frequency immediately. > >> > >> Signed-off-by: Stratos Karafotis <stratosk@xxxxxxxxxxxx> > > > > Acked-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx> > > Rafael, > > I applied it here with my Ack over my patches, for getting a run by > "kbuild test robot". > > http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/cpufreq-for-3.10 Thanks, but I'm still not entirely sure about the have_multiple_policies stuff (yes, I saw your arguments) and the v3.10 merge window is still two months away. IOW, please slow down a bit. 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
