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? Rafael > --- > > diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c > index 1aaf7af..8cee63e 100644 > --- a/drivers/cpufreq/cpufreq_ondemand.c > +++ b/drivers/cpufreq/cpufreq_ondemand.c > @@ -754,12 +754,7 @@ static int cpufreq_governor_dbs(struct cpufreq_policy *policy, > > 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; > } > ----------------------------------------------------------------------------------- > This email message is for the sole use of the intended recipient(s) and may contain > confidential information. Any unauthorized review, use, disclosure or distribution > is prohibited. If you are not the intended recipient, please contact the sender by > reply email and destroy all copies of the original message. > ----------------------------------------------------------------------------------- > > -- 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
