From patchwork Fri Nov 3 13:36:42 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Redpath X-Patchwork-Id: 117898 Delivered-To: patch@linaro.org Received: by 10.140.22.164 with SMTP id 33csp3476072qgn; Fri, 3 Nov 2017 06:36:52 -0700 (PDT) X-Google-Smtp-Source: ABhQp+TpdQrwhQ7YMaTHnkmZgSB4gs7Px6FCGFdfKumphKCXMy0MGgYtlPj/t+6BtvlJufRwkRyn X-Received: by 10.84.131.111 with SMTP id 102mr6850658pld.178.1509716212680; Fri, 03 Nov 2017 06:36:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1509716212; cv=none; d=google.com; s=arc-20160816; b=EiztVIlAHN0fXQRz04ygDOPedm/K8TDPxDWWphru6/9P2hJSvtqfZHtxpJHz7frf73 Eli+eQ2yEb2EwqS+GhK4gfa8GegAlbsZopPMHY0TKtilKSKBPUhNMul82aNBtqCD1Mxa Fzqa+dE31S4PEZJ0ElViWFEJB0Z/xpDwyTDp+g4tJhoWJ5l4qN8vt8bKn2pZOfOTJTzG rnDR43eyY2Z+A9lgqzniTCm2xl4GlJNyDbCQs1RA/lJ1HPji/5kI9B4Ouy0j+IydQl7V vHBEw4pBtCem1KeDKkveQDqBO/mJTMbLsobdofSYX1kjbkB0fC++J/Dp56jJgQ6trwxn NT/g== 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:message-id:date :subject:cc:to:from:arc-authentication-results; bh=J5K2vZSNB7aq474/zxyumIBVp1VUXWyLMXqKKxxXksk=; b=WfRdN2WRiQEsyOUr1jpdd8Z4iyZXqzVm+/9g5Lbe0kaF/8JgN6Ov56FKuILZ8fxhST 460+1XWJJ7I6CYJoe4zqmAHfzNWRJo/4TtAbNRl4pZcpej5QhXtQbtl7ar4knAhJG0QQ FYlFFGbi/Ic7iL4hEksfk0encyssaCPa0Yc4rkEXyGsEmiEGVDzYeJT2tw67j7CtlMEj 6zKImmNcjVWic24bni6b89CpcVy4vD4anIKZyNtv8b9shAm/doZTDFpk8XZkA9QicOkG j+tmqwCK07acOGcvmfOjzfbtvgSQwn/VmwqByetfTyPoLruNne2kogOEmCPYZ4v5Qupd w9aQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k8si6055595pgo.453.2017.11.03.06.36.52; Fri, 03 Nov 2017 06:36:52 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751676AbdKCNgv (ORCPT + 11 others); Fri, 3 Nov 2017 09:36:51 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:42968 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750857AbdKCNgu (ORCPT ); Fri, 3 Nov 2017 09:36:50 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3C9881435; Fri, 3 Nov 2017 06:36:50 -0700 (PDT) Received: from e108031-lin.cambridge.arm.com (e108031-lin.cambridge.arm.com [10.1.211.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 93A823F3E1; Fri, 3 Nov 2017 06:36:48 -0700 (PDT) From: Chris Redpath To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Cc: Morten Rasmussen , Dietmar Eggemann , Chris Redpath , "Rafael J . Wysocki" , Viresh Kumar , Ingo Molnar , Peter Zijlstra Subject: [PATCH v3] cpufreq: schedutil: Examine the correct CPU when we update util Date: Fri, 3 Nov 2017 13:36:42 +0000 Message-Id: <20171103133642.8636-1-chris.redpath@arm.com> X-Mailer: git-send-email 2.13.1.449.g02a2850 In-Reply-To: <20171103034022.GD4240@vireshk-i7> References: <20171103034022.GD4240@vireshk-i7> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org After 674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks") We stopped always reading utilization for the cpu we are running the governor on, and instead read it for the cpu which we've been told has updated utilization. This is stored in sugov_cpu->cpu. The value is set in sugov_register but we clear it in sugov_start which leads to always looking at the utilization of CPU0 instead of the correct one. Let's fix this by consolidating the initialization code into sugov_start(). Fixes: 674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks") Signed-off-by: Chris Redpath Reviewed-by: Patrick Bellasi Reviewed-by: Brendan Jackman Cc: Rafael J. Wysocki Cc: Viresh Kumar Cc: Ingo Molnar Cc: Peter Zijlstra --- kernel/sched/cpufreq_schedutil.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) -- 2.13.1.449.g02a2850 Acked-by: Viresh Kumar diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index 6c1a7fcfa2a7..dc68a1ccdb33 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -728,6 +728,7 @@ static int sugov_start(struct cpufreq_policy *policy) struct sugov_cpu *sg_cpu = &per_cpu(sugov_cpu, cpu); memset(sg_cpu, 0, sizeof(*sg_cpu)); + sg_cpu->cpu = cpu; sg_cpu->sg_policy = sg_policy; sg_cpu->flags = SCHED_CPUFREQ_RT; sg_cpu->iowait_boost_max = policy->cpuinfo.max_freq; @@ -793,11 +794,6 @@ struct cpufreq_governor *cpufreq_default_governor(void) static int __init sugov_register(void) { - int cpu; - - for_each_possible_cpu(cpu) - per_cpu(sugov_cpu, cpu).cpu = cpu; - return cpufreq_register_governor(&schedutil_gov); } fs_initcall(sugov_register);