From patchwork Fri Jun 9 10:15:54 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 103452 Delivered-To: patch@linaro.org Received: by 10.140.91.77 with SMTP id y71csp134370qgd; Fri, 9 Jun 2017 03:16:27 -0700 (PDT) X-Received: by 10.99.177.5 with SMTP id r5mr2432344pgf.21.1497003387519; Fri, 09 Jun 2017 03:16:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497003387; cv=none; d=google.com; s=arc-20160816; b=BYFw/RquTlnimogFlKY8NsiCpR75JL4zd107AaNwQIl4p5AlQzsW/QyDSwpDbM2xBl o3KefxxNRSRjHkeoaG67dzp47obv7QEDqOdM9CemZiJ9lyhE9liFFo7rhwf6pj0lKdBU wSC0Xd3Ak2qlmEPqNNSNmM4tQlAUHr4zl0Q3YTbyXZ1WYKfkQAQYZvmDovSv3R6OmxmY NJmpKUT9HnAOdRx2AuO6S4fO89iUaLCKq2sfqWXzfdFdsMSw0Ba1R6gVUDPEUMoD+2iE I653mopdBMDto8tuDSnQgjWeE313Wee/wD8iiYqblfXWvmVUL43/CzZNMA2foZBXH2GH iuAg== 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=0QbDX/mZmYSoCmTdjiKRTSBdoKx7mrzT7QcdJDyyNUs=; b=PRWvF6MPn3o1NwuhUnwZQq9p8eUJiloeh5gg0bm52a/eRVz+j6ARtdT+S+51AgDF9n wgdVao0cpNS77pAtedNqiqT15n+sOygl1ZmqgY5lviAwn5ovCMWi8zsHxZpWFnODnOPS FN4jEXYunZiClWpMlDsWbTzeJguUroLLyqf216ZsScVk0r/yuJ2JBP+Sq3gJtu/I8saT IYtlJmM5GOvI0J9SZtE+4PpSJC8xJLzaAOg9hCfisAQrF4wzM5IGmM4Zz4otrdURxhfj F4Dj/B6aGS0zd7ZHMcloMIKcXUuVbLDImk5tfDHS53jllcpFb4xw/A8FrKAr0IjpM5hX JNCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org; 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 a81si629412pfl.237.2017.06.09.03.16.27; Fri, 09 Jun 2017 03:16:27 -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; 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 S1751639AbdFIKQR (ORCPT + 25 others); Fri, 9 Jun 2017 06:16:17 -0400 Received: from mail-pg0-f44.google.com ([74.125.83.44]:34753 "EHLO mail-pg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751610AbdFIKQO (ORCPT ); Fri, 9 Jun 2017 06:16:14 -0400 Received: by mail-pg0-f44.google.com with SMTP id v18so25274479pgb.1 for ; Fri, 09 Jun 2017 03:16:09 -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=0QbDX/mZmYSoCmTdjiKRTSBdoKx7mrzT7QcdJDyyNUs=; b=F0NupnS773TW1ZqP4wxGzIPnW8Taw4/8I3ZSdgJlO2oCuctT3bbSSCa/EykyIQDcS+ uwsQc67ZkTLIPxBFch+9cJmXMGlu2lp6pqqRtcICxwej97Meq0b5TfbrzSeXAYBi7YhL 3vUw5M5XCXChtenGP5o2s7QCA6r4+A+4JjwWk= 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=0QbDX/mZmYSoCmTdjiKRTSBdoKx7mrzT7QcdJDyyNUs=; b=Al3yTyKa0+XiL5UKu6NDzr6uTrwjXrSndIBOn/ZiNTOwRVNFyqc10lpT4Rnc5NuVbP 8nmEqGYODd+7cXV5FGOJyB2DRZ4Bhy6mLPV1O7c6M9d+5ge7BHfG+u0V9r10LPGOJQpa PB++KA1EjkPmphW+YQvaPagBKF52tr8FYxBbs3D/7Mpc49+Euqw7+l4DfYA3KvcTvsJM szVM8rBMx6UH5UOn+/+BQjRIIihERxQ85A7n0sQoLlPuWzFe/U8dI2lJaaOF89Qf/4C0 6GaNDuFg6YtZmjdRuL2hhCtn7GLib4h0L228WS6GJQwmIh5Y2uxSaze3FS73sYIO5I4V giZg== X-Gm-Message-State: AODbwcAiQ1zU/lZlrXgLdshxKWyKnWfZy48gXTjy/ZO6jqhtC1b5FB3n N8WHCqajgHXTKWUZ X-Received: by 10.84.229.70 with SMTP id d6mr39504789pln.263.1497003368894; Fri, 09 Jun 2017 03:16:08 -0700 (PDT) Received: from localhost ([122.172.91.138]) by smtp.gmail.com with ESMTPSA id u73sm1998814pfi.105.2017.06.09.03.16.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 03:16:08 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki , Ingo Molnar , Peter Zijlstra Cc: Viresh Kumar , linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Vincent Guittot , Juri Lelli , patrick.bellasi@arm.com, john.ettedgui@gmail.com, Srinivas Pandruvada , Joel Fernandes , Morten Rasmussen Subject: [PATCH 1/3] cpufreq: schedutil: Restore cached_raw_freq behavior Date: Fri, 9 Jun 2017 15:45:54 +0530 Message-Id: X-Mailer: git-send-email 2.13.0.70.g6367777092d9 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 The purpose of the "cached_raw_freq" field is to avoid a call to cpufreq_driver_resolve_freq() when the next selected frequency is same as the one selected last time and we can use sg_policy->next_freq then. With the recent changes (reduce frequencies slower), we update the next frequency at the very last moment from sugov_update_commit() and that breaks the working of cached_raw_freq somewhat. Here is an example to illustrate what happens now. Min freq: 1 GHz Max and current freq: 4 GHz - get_next_freq() gets called and it calculates the next frequency to be 1 GHz and so it updates cached_raw_freq as 1 GHz as well. It then calls cpufreq_driver_resolve_freq() and that also returns 1 GHz. - We then call sugov_update_commit() and it updates the sg_policy->next_freq to 2.5 GHz. - get_next_freq() gets called again and this time it calculates the next frequency as 2.5 GHz. Even when the previous next_freq was set to 2.5 GHz, we end up calling cpufreq_driver_resolve_freq() as cached_raw_freq was set to 1 GHz. Moreover, it is not right to update the target frequency after we have called cpufreq_driver_resolve_freq() as that was called to map the target frequency to the driver supported one, so that we can avoid the update completely if we are already at the driver supported frequency. Fix this by moving the newly added code to get_next_freq() before the cached_raw_freq is accessed/updated. Also add a minor comment above that code to explain why it is done. We cannot take a simple average anymore as the "freq" here can be well below policy->min and we may end up reducing the frequency drastically. Take care of that by making sure "freq" is at least as much as policy->min. Fixes: 39b64aa1c007 ("cpufreq: schedutil: Reduce frequencies slower") Signed-off-by: Viresh Kumar --- kernel/sched/cpufreq_schedutil.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) -- 2.13.0.70.g6367777092d9 diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index 622eed1b7658..1852bd73d903 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -101,9 +101,6 @@ static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time, if (sg_policy->next_freq == next_freq) return; - if (sg_policy->next_freq > next_freq) - next_freq = (sg_policy->next_freq + next_freq) >> 1; - sg_policy->next_freq = next_freq; sg_policy->last_freq_update_time = time; @@ -151,6 +148,17 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy, freq = (freq + (freq >> 2)) * util / max; + /* + * Reduce frequency gradually to avoid undesirable performance drops. + * Before that we need to make sure that freq >= policy->min, else we + * may still end up reducing frequency rapidly. + */ + if (freq < policy->min) + freq = policy->min; + + if (sg_policy->next_freq > freq) + freq = (sg_policy->next_freq + freq) >> 1; + if (freq == sg_policy->cached_raw_freq && sg_policy->next_freq != UINT_MAX) return sg_policy->next_freq; sg_policy->cached_raw_freq = freq; From patchwork Fri Jun 9 10:15: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: 103454 Delivered-To: patch@linaro.org Received: by 10.140.91.77 with SMTP id y71csp134495qgd; Fri, 9 Jun 2017 03:16:47 -0700 (PDT) X-Received: by 10.84.209.199 with SMTP id y65mr39941215plh.205.1497003407290; Fri, 09 Jun 2017 03:16:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497003407; cv=none; d=google.com; s=arc-20160816; b=OOZWJjej3OvebDDumitt/+DzMj+ZQtmpa0d0zv1HgKm050qghRPCxzKAKt5jDZphLo t9+uFHaP3I+XKMlAx7Tby4eKBIuuLjUBp97lTffIThAyZxQI41w5UnlDUJDE5TISK+v1 Dd4wj8AIHjcEvIn2yhnDLx2SzTX51XL81m8QMunx3Yk/MIRC3fUU06q4GT4APJa/UmcN EFv9Jai6/JDoUPzYj6UwsneHxfwXuViztaO5WQ0+2b/Or4Dy9Cgx8bSLQeJuthp1zDB+ lGcmdF3CSjIipJgbgaqQ+U22lXpWCFyd1pCyu+9bnDtFht1LhrvTDcTnBQnabMxY+Xh/ DBEQ== 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=iNIPBUzu78kEopRMpFZEn3IhqMyZEPxVfPvhE9rQhL0=; b=vFoyGgojfIqBxaS8XiM4MijXoPTrNs+IZ6ALtTeE0E/SGLPSgATMw3UGXoVwa/vrMR tW+xwYC49s9ZsCjmSj91FGj11Zp9ZFEIj3QNEC1wJJS/1ZOazNryki+E4LHay6tZcvEz +Sodzwfg7TNw+CrFbVndcIojnsDrYMguCu/Jx+HOM7uvHgYWvQmszu/VSO5fCPAc80bE OH9cYEBebNfHcb8fkabpOIv7F1aLVGkIrCO8wQEqxwSlb0fSlsw/X6UIrdUL9AmRnUE8 kdaGl73RdbZSGlrvYiXRdVg1whJsFTMZnNQcvkKFeEE7z7tx2cNAcyL1zbUR6fT/wQfY cbsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org; 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 p26si6671216pgc.348.2017.06.09.03.16.47; Fri, 09 Jun 2017 03:16:47 -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; 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 S1751721AbdFIKQn (ORCPT + 25 others); Fri, 9 Jun 2017 06:16:43 -0400 Received: from mail-pf0-f169.google.com ([209.85.192.169]:32964 "EHLO mail-pf0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751616AbdFIKQP (ORCPT ); Fri, 9 Jun 2017 06:16:15 -0400 Received: by mail-pf0-f169.google.com with SMTP id 83so27095319pfr.0 for ; Fri, 09 Jun 2017 03:16:15 -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=iNIPBUzu78kEopRMpFZEn3IhqMyZEPxVfPvhE9rQhL0=; b=k1Mx5wHM7J/9J7J8OIT1aSAbSnthGvcLyyYsJcyyzIhmv5UmVfRXY12X2VMnYXiB2c A1NPo4K27WDrmQeDsfHmD1GDmnsZSm9HtyUIwrd1KTOYz3fkzCyVZM6zeyHF8ZJmKAg0 8VofnRwXtwGCwaXDiMDKP1XJFc1bM607Qwnjc= 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=iNIPBUzu78kEopRMpFZEn3IhqMyZEPxVfPvhE9rQhL0=; b=dU5NzJfXlGaEZJ1EPpz/HFmdUnu83jtrEeg9xBc1Buj/zABcJz5ACot/u23vb3zmnL F7vB3cdIUOqrRZ5P5yw65Aiu/a7qHMmL6nUoXtzBxSpsD71MBTSZA+eSWbChbCRHYBGf qLxKACeAXkp7I5G33QFWoh9yM35qjgOLRN4Fej0jQctDBQxlR3BKuRtN1byGPEzj5con hPj/Vqd3V5LLKhvDJUaDY445dTVIdNgREFr7nNCKcTYXwkAboJZ1hVilgBLat8MGPexY t0V8+LbiUfxVP7VoutzD1AzxXLKJ+zY8H1LDCX5x205upRPotYWJrC1MksqiZtIaMbLP MZdg== X-Gm-Message-State: AODbwcAOnpK683pi/bYyajdKDbcklJS3MKzFhMoKb1k4RjSfB8EFgWmO qv8CL6oHkenl4hW1 X-Received: by 10.84.135.129 with SMTP id 1mr39115233plj.57.1497003374661; Fri, 09 Jun 2017 03:16:14 -0700 (PDT) Received: from localhost ([122.172.91.138]) by smtp.gmail.com with ESMTPSA id 71sm1617192pgd.57.2017.06.09.03.16.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 03:16:14 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki , Srinivas Pandruvada , Len Brown , Viresh Kumar Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Vincent Guittot , Juri Lelli , Ingo Molnar , Peter Zijlstra , patrick.bellasi@arm.com, john.ettedgui@gmail.com, Joel Fernandes , Morten Rasmussen Subject: [PATCH 3/3] cpufreq: intel_pstate: Provide resolve_freq() to fix regression Date: Fri, 9 Jun 2017 15:45:56 +0530 Message-Id: X-Mailer: git-send-email 2.13.0.70.g6367777092d9 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 When the schedutil governor calls cpufreq_driver_resolve_freq() for the intel_pstate (in passive mode) driver, it simply returns the requested frequency as there is no ->resolve_freq() callback provided. The result is that get_next_freq() doesn't get a chance to know the frequency which will be set eventually and we can hit a potential regression as explained in the following paragraph. For example, consider the possible range of frequencies as 900 MHz, 1 GHz, 1.1 GHz, and 1.2 GHz. If the current frequency is 1.1 GHz and the next frequency (based on current utilization) is 1 GHz, then the schedutil governor will try to set the average of these as the next frequency (i.e. 1.05 GHz). Because we always try to find the lowest frequency greater than equal to the target frequency, the intel_pstate driver will end up setting the frequency as 1.1 GHz. Though the sg_policy->next_freq field gets updated with the average frequency only. And so we will finally select the min frequency when the next_freq is 1 more than the min frequency as the average then will be equal to the min frequency. But that will also take lots of iterations of the schedutil update callbacks. Fix that by providing a resolve_freq() callback. Tested on desktop with Intel Skylake processors. Fixes: 39b64aa1c007 ("cpufreq: schedutil: Reduce frequencies slower") Signed-off-by: Viresh Kumar --- drivers/cpufreq/intel_pstate.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.13.0.70.g6367777092d9 diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 029a93bfb558..e177352180c3 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -2213,6 +2213,19 @@ static int intel_cpufreq_target(struct cpufreq_policy *policy, return 0; } +unsigned int intel_cpufreq_resolve_freq(struct cpufreq_policy *policy, + unsigned int target_freq) +{ + struct cpudata *cpu = all_cpu_data[policy->cpu]; + int target_pstate; + + update_turbo_state(); + + target_pstate = DIV_ROUND_UP(target_freq, cpu->pstate.scaling); + target_pstate = intel_pstate_prepare_request(cpu, target_pstate); + return target_pstate * cpu->pstate.scaling; +} + static unsigned int intel_cpufreq_fast_switch(struct cpufreq_policy *policy, unsigned int target_freq) { @@ -2246,6 +2259,7 @@ static struct cpufreq_driver intel_cpufreq = { .flags = CPUFREQ_CONST_LOOPS, .verify = intel_cpufreq_verify_policy, .target = intel_cpufreq_target, + .resolve_freq = intel_cpufreq_resolve_freq, .fast_switch = intel_cpufreq_fast_switch, .init = intel_cpufreq_cpu_init, .exit = intel_pstate_cpu_exit,