From patchwork Wed Feb 15 17:15: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: 94031 Delivered-To: patch@linaro.org Received: by 10.182.3.34 with SMTP id 2csp2081833obz; Wed, 15 Feb 2017 09:15:58 -0800 (PST) X-Received: by 10.98.133.11 with SMTP id u11mr38762334pfd.132.1487178958437; Wed, 15 Feb 2017 09:15:58 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y11si1151145plg.84.2017.02.15.09.15.58; Wed, 15 Feb 2017 09:15:58 -0800 (PST) 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; 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 S1752245AbdBORP4 (ORCPT + 13 others); Wed, 15 Feb 2017 12:15:56 -0500 Received: from mail-pg0-f51.google.com ([74.125.83.51]:33862 "EHLO mail-pg0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751659AbdBORPz (ORCPT ); Wed, 15 Feb 2017 12:15:55 -0500 Received: by mail-pg0-f51.google.com with SMTP id z67so6505860pgb.1 for ; Wed, 15 Feb 2017 09:15:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=JKxb3LVHiNMOJrrz7QT74uXdoOt0zhiZtsWS+sjwgQg=; b=e8C56jIOoPwnxC8SeUG7e/py2Jeaps01Breud1fnCYkjOeJ7YLoIPotBiYyv6TIbeo cP96DdJLuoX7tduRbAaJnUcbKI0Kpx5l85ocekJiAkfBX2BfdwmWErbTipg/c/DKBbbv sR3IOv9HTY1qot9f47KdYYC99exh461a0NVI4= 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; bh=JKxb3LVHiNMOJrrz7QT74uXdoOt0zhiZtsWS+sjwgQg=; b=p9gOpxLMwu4xIPiLkwHKj6C39ZCeFXPHr8SejdXtfZzryzT0sBiO/eAYSdkPDpByD1 Takq1RV7UO2tG9l9sv+S4X9gkSfF4Mw/2F9HNdQVPhf+Uf3dOhVo0M4O4Vcn0BIj3rWv UHqcUwDUsS4B+XS48hXfdeteW6n4W3L99SHGImm9aFLGIZL0xj55RrtxBLwe6AoJDXMe oZryAxbBRsNXlLq3NaqKShTUvI4Xq03V9I8Df7CJwABhcpToVudBvkke5zO6+sb92Mi+ WaEE4tNQ3n+Hkhyb9hG4fBFTlZVneKc/tEpmwAOImjBXKX7YXK1a8bVa0UWDSTE9xuZJ izAw== X-Gm-Message-State: AMke39ktOmLo4mPuxeCIjjP/CPrYdER3jB2+nC3ggXcntR/NyThEPBntV2l9Dx+uQf3amFoL X-Received: by 10.84.192.137 with SMTP id c9mr44528393pld.7.1487178954804; Wed, 15 Feb 2017 09:15:54 -0800 (PST) Received: from localhost ([122.172.165.189]) by smtp.gmail.com with ESMTPSA id s21sm8620766pgg.65.2017.02.15.09.15.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 09:15:53 -0800 (PST) From: Viresh Kumar To: Rafael Wysocki , Ingo Molnar , Peter Zijlstra Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Vincent Guittot , Viresh Kumar Subject: [PATCH] cpufreq: schedutil: govern how frequently we change frequency with rate_limit Date: Wed, 15 Feb 2017 22:45:47 +0530 Message-Id: <4c9afe0a2cda5016b342f777f244c89c03cdc524.1487178939.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.7.1.410.g6faf27b Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org For an ideal system (where frequency change doesn't incur any penalty) we would like to change the frequency as soon as the load changes for a CPU. But the systems we have to work with are far from ideal and it takes time to change the frequency of a CPU. For many ARM platforms specially, it is at least 1 ms. In order to not spend too much time changing frequency, we have earlier introduced a sysfs controlled tunable for the schedutil governor: rate_limit_us. Currently, rate_limit_us controls how frequently we reevaluate frequency for a set of CPUs controlled by a cpufreq policy. But that may not be the ideal behavior we want. Consider for example the following scenario. The rate_limit_us tunable is set to 10 ms. The CPU has a constant load X and that requires the frequency to be set to Y. The schedutil governor changes the frequency to Y, updates last_freq_update_time and we wait for 10 ms to reevaluate the frequency again. After 10 ms, the schedutil governor reevaluates the load and finds it to be the same. And so it doesn't update the frequency, but updates last_freq_update_time before returning. Right after this point, the scheduler puts more load on the CPU and the CPU needs to go to a higher frequency Z. Because last_freq_update_time was updated just now, the schedutil governor waits for additional 10ms before reevaluating the load again. Normally, the time it takes to reevaluate the frequency is negligible compared to the time it takes to change the frequency. And considering that in the above scenario, as we haven't updated the frequency for over 10ms, we should have changed the frequency as soon as the load changed. This patch changes the way rate_limit_us is used, i.e. It now governs "How frequently we change the frequency" instead of "How frequently we reevaluate the frequency". One may think that this change may have increased the number of times we reevaluate the frequency after a period of rate_limit_us has expired since the last change, if the load isn't changing. But that is protected by the scheduler as normally it doesn't call into the schedutil governor before 1 ms (Hint: "decayed" in update_cfs_rq_load_avg()) since the last call. Tests were performed with this patch on a Dual cluster (same frequency domain), octa-core ARM64 platform (Hikey). Hackbench (Debian) and Vellamo/Galleryfling (Android) didn't had much difference in performance w/ or w/o this patch. Its difficult to create a test case (tried rt-app as well) where this patch will show a lot of improvements as the target of this patch is a real corner case. I.e. Current load is X (resulting in freq change), load after rate_limit_us is also X, but right after that load becomes Y. Undoubtedly this patch would improve the responsiveness in such cases. Signed-off-by: Viresh Kumar --- kernel/sched/cpufreq_schedutil.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.7.1.410.g6faf27b diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index fd4659313640..306d97e7b57c 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -92,14 +92,13 @@ static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time, { struct cpufreq_policy *policy = sg_policy->policy; - sg_policy->last_freq_update_time = time; - if (policy->fast_switch_enabled) { if (sg_policy->next_freq == next_freq) { trace_cpu_frequency(policy->cur, smp_processor_id()); return; } sg_policy->next_freq = next_freq; + sg_policy->last_freq_update_time = time; next_freq = cpufreq_driver_fast_switch(policy, next_freq); if (next_freq == CPUFREQ_ENTRY_INVALID) return; @@ -108,6 +107,7 @@ static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time, trace_cpu_frequency(next_freq, smp_processor_id()); } else if (sg_policy->next_freq != next_freq) { sg_policy->next_freq = next_freq; + sg_policy->last_freq_update_time = time; sg_policy->work_in_progress = true; irq_work_queue(&sg_policy->irq_work); }