From patchwork Thu Jun 29 10:59:08 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 106629 Delivered-To: patch@linaro.org Received: by 10.182.135.102 with SMTP id pr6csp4554174obb; Thu, 29 Jun 2017 04:00:02 -0700 (PDT) X-Received: by 10.98.112.137 with SMTP id l131mr15983334pfc.186.1498734002845; Thu, 29 Jun 2017 04:00:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498734002; cv=none; d=google.com; s=arc-20160816; b=AwRBIysfBJnE9sAhSpEDE2mDKKoWsTW8viG5X7dmZJSBK7zaWmOZ2a0bUA1aceieqP 4biF5nAjc6s/BtJ9Y8kj0692akt1v9HuMaG4yBZWvn02bBOlon/mU/lLZkVwHLbf+Grh TyBlKJSp7lUSRwoXb2LD3+OI9XIy0lgfQmC8gksGXl+Fdudq3giTpPOftPY61HUB1N7s 2tht1IVsi2/AadYXOkMcONzO1dYWWmr4C9UXiPOGKoYfv5UApYfYfAJR9MwSwQTLC4z5 OmhM+3ekDsjQLq10u3cRcxEt5NX2ItLzcjfsBil3wuR4klNfCng1N+4dsQZw5EGTBsDR kuow== 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=mS9qEPPrc3oG+oi6FOC7EcP2IM0pU/1U4Pd0viINdzQ=; b=XdXWF4gxQVQGmL3NvM6F68MYnGzZ3DPt1SeG2XHReofO5aJYYmqEPUkwX6t5M8T39K yKrw6BycFtnFK09LvlNU+j2K7ftj9u9CPA+Wf4BQjwLqUoRlrCjG1x7tRiAnwxT63Z5S Hr7mQlwGxu7OCJqkSuWHYXOpCHIaWVCIFDb4PAlsOjMzC2YOgkpRDWZ7hwvsvgOj1dmL TWDBz5wId4yIkX2PWJlwx864J+XpIjNiCYr1djJwCXsL1wRP5zC9UDP6ccCp608XSXHB YRrgh2jlFwJyE/+7wAMmud1sO0oDp47NijgkS1LJmwKcptHNdsPvDDiG5a3keXrFkcpP sY2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=LXJJ03QX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 n1si3772598pld.585.2017.06.29.04.00.02; Thu, 29 Jun 2017 04:00:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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=LXJJ03QX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 S1752750AbdF2K77 (ORCPT + 25 others); Thu, 29 Jun 2017 06:59:59 -0400 Received: from mail-pg0-f42.google.com ([74.125.83.42]:34406 "EHLO mail-pg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752701AbdF2K7f (ORCPT ); Thu, 29 Jun 2017 06:59:35 -0400 Received: by mail-pg0-f42.google.com with SMTP id t186so46526057pgb.1 for ; Thu, 29 Jun 2017 03:59:34 -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=mS9qEPPrc3oG+oi6FOC7EcP2IM0pU/1U4Pd0viINdzQ=; b=LXJJ03QXdbytEiJUBgUN0eUocStkX+j360lsgorttFg7VTSyATPOLy7V7Tr5u7JER4 acJPo3a0d9g0p5DYCuUANSI8RwNQB87t3SKTiiNxZt37+FSq+tKnkz54AV2K+6DsDS27 b0VPIali9KnrXJ8TP7MhJAHRE919NhcwkJzDo= 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=mS9qEPPrc3oG+oi6FOC7EcP2IM0pU/1U4Pd0viINdzQ=; b=F+UKz74jqWnXIjTQkPY9V0vrrXJ3mBscebNLxo7Pm8cv+7sqO+CZaPuiV/BTxYPhfV HfO/4SPrYPJGch39VI9FPIYKh+AlW8WapzC51OBwUdG3+a6da4IxrVu91IeuPBAzwbNI AQvX0tGgYRkSiD1QOpusVvaej3THK+PWv3IE1IB0w20q1xMSq2ufhQdP3WcRSpJeiMs/ /EkElIhI/WuW96OHH4ddwD4qyvJStXbL/vAlwfuNDLWSIGBCWHTAcarAllE6LsWmdq2W vOlmdLIVDIeremfWoPGUntPG0Ogvq8uUFzg1glIY79rts7AeF7PJieGBWDiJK9rB0qew B4DQ== X-Gm-Message-State: AKS2vOyTanOiqqZPdopTJmqRx8Z3GPZo4lK9e3gW5gGNIzIMNFxMB3X3 NCTrey188BjvOI+v X-Received: by 10.99.122.18 with SMTP id v18mr15207133pgc.142.1498733969390; Thu, 29 Jun 2017 03:59:29 -0700 (PDT) Received: from localhost ([122.171.238.149]) by smtp.gmail.com with ESMTPSA id h123sm8343523pgc.36.2017.06.29.03.59.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 03:59:28 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki , Viresh Kumar Cc: linux-pm@vger.kernel.org, Vincent Guittot , linux-kernel@vger.kernel.org Subject: [PATCH 5/6] cpufreq: Cap the default transition delay value to 10 ms Date: Thu, 29 Jun 2017 16:29:08 +0530 Message-Id: <1626e6781865d68bd0e666ec941048a9a6166156.1498733506.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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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 dee6fe3d8af0..cf1faba29113 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -541,7 +541,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 */