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

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

[Rafael J. Wysocki]

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?

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.
> -----------------------------------------------------------------------------------
> 
> 

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

[Thomas Renninger]

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.

Thanks,

   Thomas

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

[Rafael J. Wysocki]

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;