From patchwork Thu Jul 13 05:40:56 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 107545 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp1780098qge; Wed, 12 Jul 2017 22:41:53 -0700 (PDT) X-Received: by 10.98.211.89 with SMTP id q86mr58966700pfg.37.1499924513744; Wed, 12 Jul 2017 22:41:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1499924513; cv=none; d=google.com; s=arc-20160816; b=0/eZQixe+LazylV2+hMucqsrrTqqMN0WpILXuJcLqv+qxcQv5Gik0KfyAESd9Zuyx8 QFUjFXEg1/3/NuheTCLtFzIv3lNp4CExTGucYgSB3R2erTRAS99t6O5ec3VZi0zg57/h 6EZFbyonL9swNlvEzEKL5974uUy4AS7Ol2Y0cO/CLilpoAmlIgPsViOTsb4ZI/CrM7gr 26rRPtbRjMdfOExvdVbPnX2zj0O4jXvzjS+b+hGSLR5L8mK1nVOP9ogwqETmdVjEfe62 I4TwOkPjMiz+UrNg8fGtTOA1NSmp1m7zpK2VPWE/5pcnFFb8xBuZsb9CtU+bbaqoUKYk qqVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=GmD+Rzwsi+aeXM5Vx6C8ltpYv6Sl8SmiJVYg3XjZOaw=; b=m4Vf292PYBRpqoHvWej8MaRSNgjq4t/9sKRVMbJ4fA2nDLe0ekkyfMyDm6d+xH5a8W qkQ+j8P2EWQUfjnHiuX3IQgyUemwmi70kbh4eyGCMt29oCWv1hgifBh5ASPCtcayx2VB q31N7dBV2wQ/1x09j+8clHecruWL1LueZeyIJ5I6MwWxb1N4ykHBgMuApZPuYwJPbIc7 C9c+z4PlzecVIUfsDStD2TNOSPM2quN6eNGSile+Ya+djdEd6UydDq2W7tCEvRagaUzg +eIj/CEDqvEZ1KYnA6PMSrLsCE+z/eBbWsrY9oNUZO6qx6ROmUmX7GG9ARzV8eMlfi0s nLBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=MFDX+5n+; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q6si3490263pgq.8.2017.07.12.22.41.53; Wed, 12 Jul 2017 22:41:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.b=MFDX+5n+; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751170AbdGMFlr (ORCPT + 14 others); Thu, 13 Jul 2017 01:41:47 -0400 Received: from mail-pg0-f47.google.com ([74.125.83.47]:35400 "EHLO mail-pg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750940AbdGMFlp (ORCPT ); Thu, 13 Jul 2017 01:41:45 -0400 Received: by mail-pg0-f47.google.com with SMTP id j186so24052235pge.2 for ; Wed, 12 Jul 2017 22:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :in-reply-to:references; bh=GmD+Rzwsi+aeXM5Vx6C8ltpYv6Sl8SmiJVYg3XjZOaw=; b=MFDX+5n+k3I3aNQoIRTOsfQyQh0SYX1HV9KZbtBQrwyDEx0kifBXo2OH8a8VPCE2Uh oUfKC189+pJUCx4zk2z4GiccV+y4D4C6pdNaEGRNrfZdoJd7rULRZPo/PSgJE95AlXJ7 E59LKasG2H2L8vBp3UKoHZ4O0dhDP7K+vGb1w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:in-reply-to:references; bh=GmD+Rzwsi+aeXM5Vx6C8ltpYv6Sl8SmiJVYg3XjZOaw=; b=szBIDN7tC1wtOindtlvGOUi3jtnDxRWuwDCUmmbk1fqhbDdwUYjBevat569yEKl/SJ vTthfzIKRMrWjp16tadkvb9W1d+Qaa1mR4eEyhLZ0oagwiJaMNorb5HRCbGyh0LgzP5Q eYR2B0WJ+KduwJVo1MBjTRMTQlWpEhnY502W0rIhysbn2YDXipizH2/viPBvixKTBR4V sxZDdtWxjstmYL2SMuSagptRlao+qsmIivTvGOSUXetMavJ7Eu7KpMEkK57WUF+TZuXg VHAHa1qQ4z1KD0GJa6Joq07C28IB2YXBt8zM5JUmJl7n3P+xdD+9bbFCVRBy3+zo5IoA X8wA== X-Gm-Message-State: AIVw113tX+oNLtaeuN258fcAdoauTeL9wbMek0I9Wti6Yni4aovWwI/M 4uDPKmgJ+TeixeeW X-Received: by 10.98.14.79 with SMTP id w76mr58357550pfi.72.1499924504625; Wed, 12 Jul 2017 22:41:44 -0700 (PDT) Received: from localhost ([122.171.81.230]) by smtp.gmail.com with ESMTPSA id r1sm9916163pgo.42.2017.07.12.22.41.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 22:41:44 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki , Viresh Kumar Cc: linux-pm@vger.kernel.org, Vincent Guittot , linux@dominikbrodowski.net, linux-kernel@vger.kernel.org Subject: [RFC V2 5/6] cpufreq: Cap the default transition delay value to 10 ms Date: Thu, 13 Jul 2017 11:10:56 +0530 Message-Id: <6534daba87803a0f2a14c385a20cbb416fe6cbd8.1499853492.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.13.0.71.gd7076ec9c9cb In-Reply-To: References: In-Reply-To: References: Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org If transition_delay_us isn't defined by the cpufreq driver, the default value of transition delay (time after which the cpufreq governor will try updating the frequency again) is currently calculated by multiplying transition_latency (nsec) with LATENCY_MULTIPLIER (1000) and then converting this time to usec. That gives the exact same value as transition_latency, just that the time unit is usec instead of nsec. With acpi-cpufreq for example, transition_latency is set to around 10 usec and we get transition delay as 10 ms. Which seems to be a reasonable amount of time to reevaluate the frequency again. But for platforms where frequency switching isn't that fast (like ARM), the transition_latency varies from 500 usec to 3 ms, and the transition delay becomes 500 ms to 3 seconds. Of course, that is a pretty bad default value to start with. We can try to come across a better formula (instead of multiplying with LATENCY_MULTIPLIER) to solve this problem, but will that be worth it ? This patch tries a simple approach and caps the maximum value of default transition delay to 10 ms. Of course, userspace can still come in and change this value anytime or individual drivers can rather provide transition_delay_us instead. Signed-off-by: Viresh Kumar --- include/linux/cpufreq.h | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) -- 2.13.0.71.gd7076ec9c9cb diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index 14f0ab61ed17..f691ec2793c0 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -544,7 +544,17 @@ cpufreq_policy_transition_delay_us(struct cpufreq_policy *policy) if (latency) delay_us *= latency; - return delay_us; + /* + * For platforms that can change the frequency very fast (< 10 us), + * the above formula gives a decent transition delay. But for platforms + * where transition_latency is in milliseconds, it ends up giving + * unrealistic values. + * + * Cap the default transition delay to 10 ms, which seems to be a + * reasonable amount of time after which we should reevaluate the + * frequency. + */ + return min(delay_us, (unsigned int)10000); } /* Governor attribute set */