From patchwork Wed Jul 19 10:12:43 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 108266 Delivered-To: patch@linaro.org Received: by 10.182.45.195 with SMTP id p3csp666184obm; Wed, 19 Jul 2017 03:15:05 -0700 (PDT) X-Received: by 10.84.216.6 with SMTP id m6mr2366251pli.299.1500459305491; Wed, 19 Jul 2017 03:15:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1500459305; cv=none; d=google.com; s=arc-20160816; b=ALLWuKCiT6RgPm988yKHHvSpinqf1DCdnB5wAEU/YQmJZybqkRtSrMe42hqHdg9ebU MA9iaQYwgN4QTk+0kAEa3rn5+bKOVq4dN8mQofOifr1mgScBoS03KY0GDIbikg6qoJ7B Jpquvr+Y8glttg6q2QDQjqGFveSjtv/C2eE26lCeUPbGIjDACyOoPSTAkwQtQPOQ1jLY hMSZmblhmlubwLtbFidll1siei8ibjgqaCHBM4kVitgNc/emOoo3jD2+6K+pWsqECvpN 4zrg1MbLpxTV9ZDm/oS6PLXpVBJX5/DYDeCSumNCEBGc/P1dYUQSpK6f6df2X48C/V34 0G7g== 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=xYHREeIHpKkzE7W2355ZPaRIpSZ9agrHodJK4ed6LI0=; b=Jpo+6eyJxgJiam/BUxeOaY8YazNaZvg9W8BZBcbt0cyPBTqZ40dd8WspATn3MWhNx1 jv6QAcs+x1Ih4nhU8YRQzdsDUl8I2ayiOsNf/Rtoml9oTh8BdQmOY8So8EOsqDLT3X13 PZAMlkXwNkcmyjUYsWVve9ModhuLdp0YCyJEAZd5b3djg38n6l95K1Re0JKB/SSbTIkK EGdBz6Hgm8r3j2UwlNg6Vh7InPiRcS9mpIXRFtok2Zh9RhDhdwgC5RBn2JK6VfKVx6ml zny1g3Z2gDdKA5vJgMibLBizRCNa67cFO9rbGsUOys74yeNqKaXdMcrfefHe8QVrV35N fr0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=FOEEsiZd; 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 1si2487200pln.153.2017.07.19.03.15.05; Wed, 19 Jul 2017 03:15:05 -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=FOEEsiZd; 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 S1754513AbdGSKPC (ORCPT + 13 others); Wed, 19 Jul 2017 06:15:02 -0400 Received: from mail-pf0-f170.google.com ([209.85.192.170]:33585 "EHLO mail-pf0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754078AbdGSKNV (ORCPT ); Wed, 19 Jul 2017 06:13:21 -0400 Received: by mail-pf0-f170.google.com with SMTP id s70so16176198pfs.0 for ; Wed, 19 Jul 2017 03:13:20 -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=xYHREeIHpKkzE7W2355ZPaRIpSZ9agrHodJK4ed6LI0=; b=FOEEsiZdQkPY5IfOgBshmjc/YN0GzMh8s7T9U59h6rQSd+ofhVafbRQrBcesi6jVrZ CTBNN3JdPLvRsBzeh2YjGGpskTxR2drAwxO6CgLfnWfZWwmSaSaVfMeIt6LUthUYlIvT iFNdFcKdocW3YMbIR6DlZfhHsICp23D6qcyS4= 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=xYHREeIHpKkzE7W2355ZPaRIpSZ9agrHodJK4ed6LI0=; b=A+IMKB5x5vs3AZWtOM7MGFDgACxEfkaQg8USDLMBs7n2aOE0pAesdX2WA3AAhn2PQh 6PWFOgxXsUvKx4AGF4R+4OYubUmL3SOIQWyzdALQNi93Gr3a1il4WAwu6SVC7pyF1cf0 ACHwzU7ep1ybRB3LGfxnKLQYWO9B+eWiDZD1G8l9MQ1GTwBq2CsPsiQ79oTLhyDqQfrI moutIgLijbPS5AVgDN90Xt0ZgjdJ2TNFnmgNVyqsvyCVZVphSqFCu71q8GOvudER2Udb 7Q5/z0NjKC+N91brtq3ryCpwhX0O/QwF0ovZymnpXe8i64AApHNqnmlJ/OqRHqAC+snr +1Xg== X-Gm-Message-State: AIVw112HcgylF9qLXFaz5T9FPknWVXGdb1eKGokXJi6Y3JM2Rk/3S6SM KTK+hW6OxlW8cgii X-Received: by 10.84.206.37 with SMTP id f34mr2390146ple.262.1500459200473; Wed, 19 Jul 2017 03:13:20 -0700 (PDT) Received: from localhost ([122.167.171.93]) by smtp.gmail.com with ESMTPSA id 85sm12431594pfr.90.2017.07.19.03.13.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 03:13:19 -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: [PATCH V3 3/9] cpufreq: Cap the default transition delay value to 10 ms Date: Wed, 19 Jul 2017 15:42:43 +0530 Message-Id: <1b93c94cb8b4914314e4f50304c3cb11c53d8b14.1500373914.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 --- drivers/cpufreq/cpufreq.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) -- 2.13.0.71.gd7076ec9c9cb Signed-off-by: Viresh Kumar diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index c426d21822f7..d00cde871c15 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -532,8 +532,19 @@ unsigned int cpufreq_policy_transition_delay_us(struct cpufreq_policy *policy) return policy->transition_delay_us; latency = policy->cpuinfo.transition_latency / NSEC_PER_USEC; - if (latency) - return latency * LATENCY_MULTIPLIER; + if (latency) { + /* + * 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(latency * LATENCY_MULTIPLIER, (unsigned int)10000); + } return LATENCY_MULTIPLIER; } From patchwork Wed Jul 19 10:12:47 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 108261 Delivered-To: patch@linaro.org Received: by 10.182.45.195 with SMTP id p3csp664710obm; Wed, 19 Jul 2017 03:13:36 -0700 (PDT) X-Received: by 10.84.178.37 with SMTP id y34mr2375420plb.223.1500459216339; Wed, 19 Jul 2017 03:13:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1500459216; cv=none; d=google.com; s=arc-20160816; b=VsbsrxB6yTHDdN311NnAlGjdgIbCHOz0BAKIGmyFtQhII7k8kCDewUtL90KXaS3V/p gUqLhhpR8crcdZ30Et4xy0r2iyaUP5PaQxpxrh32IRRDfupkiW8dXMVC00OFSCNPA1ks tocVHiwbgWDl5G18RWlo3rBQT3ac+lLW6h39/eQUYYRxXH3G/piFS7rJUXnT35uZf2fp J5WR096iMjrHSIJb0wy94F2ipi4MmrjFDykpVbXiLiFH9KI0TlL546IRJf7MmScde1k1 MaoDftDy8BsxgAajoQex1DucmrW4W/DpVWTIahfR+FDL0nEj9bAoCQV7RV/NRwUL2dY0 xW9g== 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=Ey/mtILMnKSFbFJcQG0WjxXyE8iHL1OzEgXOQzBg0S8=; b=vexp9RNiFjVaoYP9uxIzNZjZGFDteBrbExTOBzTXXApQJ5/DLfTF/rNJyzjVL+3P3F iROiqeeMVcdB1kkjiKCwwBOUiEkcT/PzKk4SICc3jUoRWamAyP7Y0JFBnLfOJ43I/xVC oi5UMfbDu/noLcCozbMQx9un/OOkAec8ZjJtcNvUIi53HzoZROGIHA9zuUTsiaZB2B3v CylpeQG3vOZ9OBia9cAtb9Y+WAzw0mANqCZWzGPdVGcZN9KoLiZVXpdpo9AScyKcQL5p 06+DO9eAvO+gC9bfij42S5JQUWcPCQ0g4sjhngtRVtz6BiOHIyuOnTwRNyHggelUt9zl swqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=kvAmP7ax; 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 44si4052476plb.248.2017.07.19.03.13.35; Wed, 19 Jul 2017 03:13:36 -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=kvAmP7ax; 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 S932312AbdGSKNe (ORCPT + 13 others); Wed, 19 Jul 2017 06:13:34 -0400 Received: from mail-pf0-f173.google.com ([209.85.192.173]:36487 "EHLO mail-pf0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932078AbdGSKNc (ORCPT ); Wed, 19 Jul 2017 06:13:32 -0400 Received: by mail-pf0-f173.google.com with SMTP id o88so18903342pfk.3 for ; Wed, 19 Jul 2017 03:13:32 -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=Ey/mtILMnKSFbFJcQG0WjxXyE8iHL1OzEgXOQzBg0S8=; b=kvAmP7axtTE7ME1703PAROfHwiRBnrEWj1s2bPh3jou3uRxcesNBMQaScIs4DiRwSA LwLTvjzmTWQLhGTmnuREwhjAmEeBFl4iGt1QWImWgBVT91bJxyHuSYIHXGJd4f6Xiqd4 LOxyLJdvGZIHVtz+SYJENKBltXHdqkD+VqTpo= 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=Ey/mtILMnKSFbFJcQG0WjxXyE8iHL1OzEgXOQzBg0S8=; b=VXRwQKK7hRkFO4zMSPV3plkWUfmH/nx7ZyTvdVbXTxaKRAyRhSa8dnXfMl+oAbM6ci K0UHhx+46csYnCng2kQAmc1zIW10zblQlbtBbzXwyRHdbzJZpaPvqCiAajWtNWSmZ/4u 1Yc1DRi6YqEF3VB+VOMYmTJs73Ef66A1Ar+xWF5t22rh8jTqS+JrBsrQxbgJf6tKmSRl OP4ebTHZuh20or6usrVRf2UptGqoCRGcdkEYts93xaY5SI74ukbswJqnZpXuy1/NDbU8 524+ZlqB/Xx4HQCNBwxne6DQdH6c43udexu8iF7wAfhQ/8i3GJkFiwrR4OLbDwnBZodS UQ2w== X-Gm-Message-State: AIVw111UuOSmtBhfTIaJEyaDwuFl+3ZdB2w1j9mOmt5chlXmhOb5UqHs ad2USI7qfwOhn83W X-Received: by 10.84.236.76 with SMTP id h12mr2438062pln.88.1500459212092; Wed, 19 Jul 2017 03:13:32 -0700 (PDT) Received: from localhost ([122.167.171.93]) by smtp.gmail.com with ESMTPSA id 124sm9592305pgi.62.2017.07.19.03.13.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 03:13:31 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki , Ingo Molnar , Peter Zijlstra Cc: Viresh Kumar , linux-pm@vger.kernel.org, Vincent Guittot , linux@dominikbrodowski.net, linux-kernel@vger.kernel.org Subject: [PATCH V3 7/9] cpufreq: schedutil: Set dynamic_switching to true Date: Wed, 19 Jul 2017 15:42:47 +0530 Message-Id: <4bc6051ec75b42cf91810d71cc8581f4ddcf93f2.1500373914.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 Set dynamic_switching to 'true' to disallow use of schedutil governor for platforms with transition_latency set to CPUFREQ_ETERNAL, as they may not want to do automatic dynamic frequency switching. Signed-off-by: Viresh Kumar --- kernel/sched/cpufreq_schedutil.c | 1 + 1 file changed, 1 insertion(+) -- 2.13.0.71.gd7076ec9c9cb diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index 89c4dd9777bb..45fcf21ad685 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -646,6 +646,7 @@ static void sugov_limits(struct cpufreq_policy *policy) static struct cpufreq_governor schedutil_gov = { .name = "schedutil", .owner = THIS_MODULE, + .dynamic_switching = true, .init = sugov_init, .exit = sugov_exit, .start = sugov_start,