From patchwork Mon May 9 21:20:14 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steve Muckle X-Patchwork-Id: 67380 Delivered-To: patch@linaro.org Received: by 10.140.92.199 with SMTP id b65csp1798599qge; Mon, 9 May 2016 14:21:16 -0700 (PDT) X-Received: by 10.67.1.233 with SMTP id bj9mr53226744pad.46.1462828874344; Mon, 09 May 2016 14:21:14 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id qz3si40881313pab.228.2016.05.09.14.21.14; Mon, 09 May 2016 14:21:14 -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=neutral (body hash did not verify) header.i=@linaro.org; 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=fail (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753088AbcEIVUx (ORCPT + 13 others); Mon, 9 May 2016 17:20:53 -0400 Received: from mail-pf0-f175.google.com ([209.85.192.175]:34345 "EHLO mail-pf0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752869AbcEIVUZ (ORCPT ); Mon, 9 May 2016 17:20:25 -0400 Received: by mail-pf0-f175.google.com with SMTP id y69so79525394pfb.1 for ; Mon, 09 May 2016 14:20:25 -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; bh=3ceE4wrZs7T639bBRPfn9fl72NV8ElouWoQlyduDKo4=; b=dpRtTqLpM0YqqtpKy+MSMSk1C/c0xDF24u7HkTwmkPh1U+FNn+zhrRgoVk2nXdYUpg c/Dy2u4fIg6IknA6qebH2zMjWBofPSFbqRAwYFSWDV0ojQrRyF1cvJEm2o2z69EdC6AW z/bFtmlHdv7aKtMS/MYaLFRmm2hD/hLS/nJyw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=3ceE4wrZs7T639bBRPfn9fl72NV8ElouWoQlyduDKo4=; b=Zfa1sA2iQ0kdUnmPlW6Si2JenuQuFkMSEIKQ+Ay2MnXtvxAUap9tG4p4OERQFOnDB8 LPuD5lzgWjzoqFvTettf5K9ZVT6FeYTHAwNP487oCwZu7ynlMHDCg/Mwe9gLsFwRxXjZ JPcwVSYDsT9t2lE/8stO27PFt5vxmgSzm5PaHSGyhCRfBlYIg8TfBiHjW0oqpTNbeR8l d4k1TeRas3U8odVWQi5IeFyGz6wAPlTXoLkJrro7hXflW1UIaH60SRlLJs98/CJ41wTt TIYhh8V5Q2Z0EbD7z+F0iAU+N3vaiCVEity+UO+Qe3W0b6MJOeVFEvhcEl3LCK6seiRi xKkw== X-Gm-Message-State: AOPr4FU31B2bh1RYD0MXRnIX2uEJLZRAbcvDN4JxOXF/B55U4c6DSKWn1sA9E0/dHvHaxngJ X-Received: by 10.98.96.134 with SMTP id u128mr37436425pfb.13.1462828824744; Mon, 09 May 2016 14:20:24 -0700 (PDT) Received: from graphite.smuckle.net (cpe-76-167-105-107.san.res.rr.com. [76.167.105.107]) by smtp.gmail.com with ESMTPSA id g5sm42815345pac.1.2016.05.09.14.20.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 09 May 2016 14:20:24 -0700 (PDT) From: Steve Muckle X-Google-Original-From: Steve Muckle To: Peter Zijlstra , Ingo Molnar , "Rafael J. Wysocki" Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Vincent Guittot , Morten Rasmussen , Dietmar Eggemann , Juri Lelli , Patrick Bellasi , Michael Turquette , Viresh Kumar , Srinivas Pandruvada , Len Brown Subject: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged Date: Mon, 9 May 2016 14:20:14 -0700 Message-Id: <1462828814-32530-6-git-send-email-smuckle@linaro.org> X-Mailer: git-send-email 2.4.10 In-Reply-To: <1462828814-32530-1-git-send-email-smuckle@linaro.org> References: <1462828814-32530-1-git-send-email-smuckle@linaro.org> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org The rate limit timestamp (last_freq_update_time) is currently advanced anytime schedutil re-evaluates the policy regardless of whether the CPU frequency is changed or not. This means that utilization updates which have no effect can cause much more significant utilization updates (which require a large increase or decrease in CPU frequency) to be delayed due to rate limiting. Instead only update the rate limiting timstamp when the requested target-supported frequency changes. The rate limit will now apply to the rate of CPU frequency changes rather than the rate of re-evaluations of the policy frequency. Signed-off-by: Steve Muckle --- kernel/sched/cpufreq_schedutil.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 2.4.10 -- 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 diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index e185075fcb5c..4d2907c8a142 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -117,12 +117,11 @@ static void sugov_update_commit(struct sugov_cpu *sg_cpu, int cpu, u64 time, struct sugov_policy *sg_policy = sg_cpu->sg_policy; struct cpufreq_policy *policy = sg_policy->policy; - sg_policy->last_freq_update_time = time; - if (sg_policy->next_freq == next_freq) { trace_cpu_frequency(policy->cur, cpu); return; } + sg_policy->last_freq_update_time = time; sg_policy->next_freq = next_freq; if (sugov_queue_remote_callback(sg_policy, cpu))