Re: [PATCH] cpufreq: ondemand: update frequency when limits are relaxed

["Rafael J. Wysocki" <rjw@sisk.pl>]

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@nvidia.com>
> > > 
> > > 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@nvidia.com>
> > 
> > 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;