From patchwork Fri Sep 7 20:48:55 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rafael Wysocki X-Patchwork-Id: 1425061 Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id 13D9CDF283 for ; Fri, 7 Sep 2012 20:42:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756873Ab2IGUmj (ORCPT ); Fri, 7 Sep 2012 16:42:39 -0400 Received: from ogre.sisk.pl ([193.178.161.156]:42803 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753599Ab2IGUmi (ORCPT ); Fri, 7 Sep 2012 16:42:38 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ogre.sisk.pl (Postfix) with ESMTP id 08E171DD666; Fri, 7 Sep 2012 22:45:48 +0200 (CEST) Received: from ogre.sisk.pl ([127.0.0.1]) by localhost (ogre.sisk.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11305-08; Fri, 7 Sep 2012 22:45:36 +0200 (CEST) Received: from ferrari.rjw.lan (89-67-90-11.dynamic.chello.pl [89.67.90.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ogre.sisk.pl (Postfix) with ESMTP id B7A3D1DD45A; Fri, 7 Sep 2012 22:45:36 +0200 (CEST) From: "Rafael J. Wysocki" To: Thomas Renninger Subject: Re: [PATCH] cpufreq: ondemand: update frequency when limits are relaxed Date: Fri, 7 Sep 2012 22:48:55 +0200 User-Agent: KMail/1.13.6 (Linux/3.6.0-rc3+; KDE/4.6.0; x86_64; ; ) Cc: Michal Pecio , "cpufreq@vger.kernel.org" , "linux-pm@vger.kernel.org" , ACPI Devel Mailing List References: <201209062340.33610.rjw@sisk.pl> <201209071013.56871.trenn@suse.de> In-Reply-To: <201209071013.56871.trenn@suse.de> MIME-Version: 1.0 Message-Id: <201209072248.55384.rjw@sisk.pl> X-Virus-Scanned: amavisd-new at ogre.sisk.pl using MkS_Vir for Linux Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org 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 > > > > > > 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 > > > > 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(-) -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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;