On Friday, September 07, 2012, Thomas Renninger wrote: > On Thursday, September 06, 2012 11:40:33 PM Rafael J. Wysocki wrote: > > On Friday, August 31, 2012, Michal Pecio wrote: > > > From: Michal Pecio <mpecio@xxxxxxxxxx> > > > > > > Reevaluate CPU load and update frequency immediately whenever limits > > > are changed. Currently ondemand doesn't do so when limits are relaxed, > > > wasting power on CPUs with relatively low sampling rate. > > > Also, update the prev_cpu_* variables on frequency transitions. Their > > > old values aren't valid anymore because the governor assumes constant > > > frequency during entire sampling period. > > > > > > Signed-off-by: Michal Pecio <mpecio@xxxxxxxxxx> > > > > Well, this makes sense to me. > > > > Thomas, what do you think? > Looks fine to me as well. > But the same should be done in the conservative driver as well then. > Could you send another, separate patch doing the same in > cpufreq_conservative.c. Do you mean something like the appended patch? Rafael --- drivers/cpufreq/cpufreq_conservative.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) Index: linux/drivers/cpufreq/cpufreq_conservative.c =================================================================== --- linux.orig/drivers/cpufreq/cpufreq_conservative.c +++ linux/drivers/cpufreq/cpufreq_conservative.c @@ -576,14 +576,7 @@ static int cpufreq_governor_dbs(struct c case CPUFREQ_GOV_LIMITS: mutex_lock(&this_dbs_info->timer_mutex); - if (policy->max < this_dbs_info->cur_policy->cur) - __cpufreq_driver_target( - this_dbs_info->cur_policy, - policy->max, CPUFREQ_RELATION_H); - else if (policy->min > this_dbs_info->cur_policy->cur) - __cpufreq_driver_target( - this_dbs_info->cur_policy, - policy->min, CPUFREQ_RELATION_L); + dbs_check_cpu(this_dbs_info); mutex_unlock(&this_dbs_info->timer_mutex); break; -- 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
