From patchwork Fri Jul 28 06:46:38 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 108871 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp31181qge; Thu, 27 Jul 2017 23:47:56 -0700 (PDT) X-Received: by 10.98.217.145 with SMTP id b17mr6625965pfl.70.1501224475939; Thu, 27 Jul 2017 23:47:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1501224475; cv=none; d=google.com; s=arc-20160816; b=Yd8y/exfvC67u5OXIKBBmxIhpWd6+QgSX+f9oxe3gZ/8vjPLnytPaE+xuU08KCbfiZ GaoTAkQeqfiId9iO0HZk0pzRurTO4rf7Yb1fnoqOVCXcyT7HbX+NhX4L9JS2AwmoklIv zO/Njsr7xrrEo/GyL1ybu7kkrU8izpcnrSaV3mMhVndehxgWv3W3icWy2Uys40S7yyIp gMv1alLSwuZLQUhaSUNb6wYQfoltkWgNB9viiq9Ur6tVS+uII9rcEfVHx/LgX8WmrIBe IoxKdVR2jpAXh8JNf0xMYLAnmuk04JxfK7MNAQCB4O31r4WvbUlAAwV/W4MsU37puaFC i/Gw== 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=uG0Zi/oIUc0iDzfz5arkocfNmY0p6c3cLl+NgrrHQ64=; b=ob36x8+ouhWYsFNEnRdHMjV33QLKxOGCVtBcnYWtQe7DLyavLWDjt3O0uWkdfBA0gP n77FpwXzzyW3MiKSLLrN4Tz4t3I7XF9fUXnEkOXeQV1S7mOszybwzujWbjwLoz5iMtKF E8nO3Rrgag1KwvKXLRE2DncR1FTwRZ2pDgnKEc8PhW/AJIf2k/XRmDvAckvhvJca9AYp aoqeV7yG/hwNd7VaGuzN9a9snKqSCOkkWgZSK4Zz25weIyxCJyV2z0I8++dXLQA3iTpO 5nUapi3Mzsxf2pLsqqyVlBTtc9Rc06IpZc/bWab3v4keJ1Lks+WbEyzUeRDbjZU0YdOj a3jA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=QFfXZw1J; 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 n1si7494215pll.730.2017.07.27.23.47.55; Thu, 27 Jul 2017 23:47:55 -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 header.b=QFfXZw1J; 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 S1751813AbdG1Grx (ORCPT + 26 others); Fri, 28 Jul 2017 02:47:53 -0400 Received: from mail-pg0-f53.google.com ([74.125.83.53]:38727 "EHLO mail-pg0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751782AbdG1Grt (ORCPT ); Fri, 28 Jul 2017 02:47:49 -0400 Received: by mail-pg0-f53.google.com with SMTP id k190so41965166pgk.5 for ; Thu, 27 Jul 2017 23:47:49 -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=uG0Zi/oIUc0iDzfz5arkocfNmY0p6c3cLl+NgrrHQ64=; b=QFfXZw1J2OL+9S96KdDP58UNqPQrFC9rXbEoPgW62SCNeJQPDmFqmce35XRq5AcgZP JZhmYMSvH9hhrQSsVjltBNLdZJABgA1qdXbfeHWRrboutCO6TCHdKLifGy4aCHiVWZ4Q 5i7aoltn2Sc3Jq6/IgRsg3MxTtncXgp69WWZk= 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=uG0Zi/oIUc0iDzfz5arkocfNmY0p6c3cLl+NgrrHQ64=; b=KTrCnSmKcObYF4i+bkijUr1oKxKhy9EfpLOhOHl/UKEO3xHgMwFL7rl4Msmbgzcmbb jI0UHcPmUNwC/frt3mVPwoIm33N8tsvVnFONhhPA187lp5z1DUFQPBU4JW+reKn+j/dH OiHUnYtWWYCTqUYXcnZFTTjeFkLDoMxSLbdkgUCge6/oVnWxJrshm5lDPxN2xyvNcARw 9PE/IkDtX/yAAbr+WCylntdnfRTMKiYRXD68B14vHdaNkdkqks6ABnD93syPjXRbtD2A qgaEZrlkZ82dOVRnh9yyoCYc0Rj19rd0IzvIeUsOASxf4QEeIn1pqE75YabdjDPATXHI r8VA== X-Gm-Message-State: AIVw110bOglR8s40ydpf+VzEFotMaqs9AcHEBmYL5H5QbFLaRKbZaWM1 TLb2KOBhQLNi9dMu X-Received: by 10.84.215.144 with SMTP id l16mr6872858pli.381.1501224468638; Thu, 27 Jul 2017 23:47:48 -0700 (PDT) Received: from localhost ([122.171.79.89]) by smtp.gmail.com with ESMTPSA id 74sm8461723pfp.21.2017.07.27.23.47.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jul 2017 23:47:47 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki , Peter Zijlstra , Viresh Kumar , Srinivas Pandruvada , Len Brown , Ingo Molnar Cc: linux-pm@vger.kernel.org, Vincent Guittot , smuckle.linux@gmail.com, juri.lelli@arm.com, Morten.Rasmussen@arm.com, patrick.bellasi@arm.com, eas-dev@lists.linaro.org, skannan@codeaurora.org, joelaf@google.com, linux-kernel@vger.kernel.org Subject: [PATCH V5 1/2] sched: cpufreq: Allow remote cpufreq callbacks Date: Fri, 28 Jul 2017 12:16:38 +0530 Message-Id: X-Mailer: git-send-email 2.13.0.71.gd7076ec9c9cb 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 With Android UI and benchmarks the latency of cpufreq response to certain scheduling events can become very critical. Currently, callbacks into cpufreq governors are only made from the scheduler if the target CPU of the event is the same as the current CPU. This means there are certain situations where a target CPU may not run the cpufreq governor for some time. One testcase to show this behavior is where a task starts running on CPU0, then a new task is also spawned on CPU0 by a task on CPU1. If the system is configured such that the new tasks should receive maximum demand initially, this should result in CPU0 increasing frequency immediately. But because of the above mentioned limitation though, this does not occur. This patch updates the scheduler core to call the cpufreq callbacks for remote CPUs as well. The schedutil, ondemand and conservative governors are updated to process cpufreq utilization update hooks called for remote CPUs where the remote CPU is managed by the cpufreq policy of the local CPU. The intel_pstate driver is updated to always reject remote callbacks. This is tested with couple of usecases (Android: hackbench, recentfling, galleryfling, vellamo, Ubuntu: hackbench) on ARM hikey board (64 bit octa-core, single policy). Only galleryfling showed minor improvements, while others didn't had much deviation. The reason being that this patch only targets a corner case, where following are required to be true to improve performance and that doesn't happen too often with these tests: - Task is migrated to another CPU. - The task has high demand, and should take the target CPU to higher OPPs. - And the target CPU doesn't call into the cpufreq governor until the next tick. Based on initial work from Steve Muckle. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq_governor.c | 3 +++ drivers/cpufreq/intel_pstate.c | 8 ++++++++ include/linux/cpufreq.h | 9 +++++++++ kernel/sched/cpufreq_schedutil.c | 31 ++++++++++++++++++++++++++----- kernel/sched/deadline.c | 2 +- kernel/sched/fair.c | 8 +++++--- kernel/sched/rt.c | 2 +- kernel/sched/sched.h | 10 ++-------- 8 files changed, 55 insertions(+), 18 deletions(-) -- 2.13.0.71.gd7076ec9c9cb diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c index eed069ecfd5e..58d4f4e1ad6a 100644 --- a/drivers/cpufreq/cpufreq_governor.c +++ b/drivers/cpufreq/cpufreq_governor.c @@ -272,6 +272,9 @@ static void dbs_update_util_handler(struct update_util_data *data, u64 time, struct policy_dbs_info *policy_dbs = cdbs->policy_dbs; u64 delta_ns, lst; + if (!cpufreq_can_do_remote_dvfs(policy_dbs->policy)) + return; + /* * The work may not be allowed to be queued up right now. * Possible reasons: diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 8bc252512dbe..d9de01399dbb 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -1747,6 +1747,10 @@ static void intel_pstate_update_util_pid(struct update_util_data *data, struct cpudata *cpu = container_of(data, struct cpudata, update_util); u64 delta_ns = time - cpu->sample.time; + /* Don't allow remote callbacks */ + if (smp_processor_id() != cpu->cpu) + return; + if ((s64)delta_ns < pid_params.sample_rate_ns) return; @@ -1764,6 +1768,10 @@ static void intel_pstate_update_util(struct update_util_data *data, u64 time, struct cpudata *cpu = container_of(data, struct cpudata, update_util); u64 delta_ns; + /* Don't allow remote callbacks */ + if (smp_processor_id() != cpu->cpu) + return; + if (flags & SCHED_CPUFREQ_IOWAIT) { cpu->iowait_boost = int_tofp(1); } else if (cpu->iowait_boost) { diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index 5f40522ec98c..b3b6e8203e82 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -562,6 +562,15 @@ struct governor_attr { size_t count); }; +static inline bool cpufreq_can_do_remote_dvfs(struct cpufreq_policy *policy) +{ + /* Allow remote callbacks only on the CPUs sharing cpufreq policy */ + if (cpumask_test_cpu(smp_processor_id(), policy->cpus)) + return true; + + return false; +} + /********************************************************************* * FREQUENCY TABLE HELPERS * *********************************************************************/ diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index 9deedd5f16a5..5465bf221e8f 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -52,6 +52,7 @@ struct sugov_policy { struct sugov_cpu { struct update_util_data update_util; struct sugov_policy *sg_policy; + unsigned int cpu; bool iowait_boost_pending; unsigned int iowait_boost; @@ -77,6 +78,21 @@ static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 time) { s64 delta_ns; + /* + * Since cpufreq_update_util() is called with rq->lock held for + * the @target_cpu, our per-cpu data is fully serialized. + * + * However, drivers cannot in general deal with cross-cpu + * requests, so while get_next_freq() will work, our + * sugov_update_commit() call may not. + * + * Hence stop here for remote requests if they aren't supported + * by the hardware, as calculating the frequency is pointless if + * we cannot in fact act on it. + */ + if (!cpufreq_can_do_remote_dvfs(sg_policy->policy)) + return false; + if (sg_policy->work_in_progress) return false; @@ -155,12 +171,12 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy, return cpufreq_driver_resolve_freq(policy, freq); } -static void sugov_get_util(unsigned long *util, unsigned long *max) +static void sugov_get_util(unsigned long *util, unsigned long *max, int cpu) { - struct rq *rq = this_rq(); + struct rq *rq = cpu_rq(cpu); unsigned long cfs_max; - cfs_max = arch_scale_cpu_capacity(NULL, smp_processor_id()); + cfs_max = arch_scale_cpu_capacity(NULL, cpu); *util = min(rq->cfs.avg.util_avg, cfs_max); *max = cfs_max; @@ -254,7 +270,7 @@ static void sugov_update_single(struct update_util_data *hook, u64 time, if (flags & SCHED_CPUFREQ_RT_DL) { next_f = policy->cpuinfo.max_freq; } else { - sugov_get_util(&util, &max); + sugov_get_util(&util, &max, sg_cpu->cpu); sugov_iowait_boost(sg_cpu, &util, &max); next_f = get_next_freq(sg_policy, util, max); /* @@ -316,7 +332,7 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time, unsigned long util, max; unsigned int next_f; - sugov_get_util(&util, &max); + sugov_get_util(&util, &max, sg_cpu->cpu); raw_spin_lock(&sg_policy->update_lock); @@ -689,6 +705,11 @@ 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); diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 755bd3f1a1a9..5c3bf4bd0327 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -1136,7 +1136,7 @@ static void update_curr_dl(struct rq *rq) } /* kick cpufreq (see the comment in kernel/sched/sched.h). */ - cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_DL); + cpufreq_update_util(rq, SCHED_CPUFREQ_DL); schedstat_set(curr->se.statistics.exec_max, max(curr->se.statistics.exec_max, delta_exec)); diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index c95880e216f6..d378d02fdfcb 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -3278,7 +3278,9 @@ static inline void set_tg_cfs_propagate(struct cfs_rq *cfs_rq) {} static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq) { - if (&this_rq()->cfs == cfs_rq) { + struct rq *rq = rq_of(cfs_rq); + + if (&rq->cfs == cfs_rq) { /* * There are a few boundary cases this might miss but it should * get called often enough that that should (hopefully) not be @@ -3295,7 +3297,7 @@ static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq) * * See cpu_util(). */ - cpufreq_update_util(rq_of(cfs_rq), 0); + cpufreq_update_util(rq, 0); } } @@ -4875,7 +4877,7 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags) * passed. */ if (p->in_iowait) - cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_IOWAIT); + cpufreq_update_util(rq, SCHED_CPUFREQ_IOWAIT); for_each_sched_entity(se) { if (se->on_rq) diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 45caf937ef90..0af5ca9e3e3f 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -970,7 +970,7 @@ static void update_curr_rt(struct rq *rq) return; /* Kick cpufreq (see the comment in kernel/sched/sched.h). */ - cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT); + cpufreq_update_util(rq, SCHED_CPUFREQ_RT); schedstat_set(curr->se.statistics.exec_max, max(curr->se.statistics.exec_max, delta_exec)); diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index eeef1a3086d1..aa9d5b87b4f8 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -2070,19 +2070,13 @@ static inline void cpufreq_update_util(struct rq *rq, unsigned int flags) { struct update_util_data *data; - data = rcu_dereference_sched(*this_cpu_ptr(&cpufreq_update_util_data)); + data = rcu_dereference_sched(*per_cpu_ptr(&cpufreq_update_util_data, + cpu_of(rq))); if (data) data->func(data, rq_clock(rq), flags); } - -static inline void cpufreq_update_this_cpu(struct rq *rq, unsigned int flags) -{ - if (cpu_of(rq) == smp_processor_id()) - cpufreq_update_util(rq, flags); -} #else static inline void cpufreq_update_util(struct rq *rq, unsigned int flags) {} -static inline void cpufreq_update_this_cpu(struct rq *rq, unsigned int flags) {} #endif /* CONFIG_CPU_FREQ */ #ifdef arch_scale_freq_capacity From patchwork Fri Jul 28 06:46:39 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 108872 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp31413qge; Thu, 27 Jul 2017 23:48:12 -0700 (PDT) X-Received: by 10.84.241.207 with SMTP id t15mr7222820plm.347.1501224492289; Thu, 27 Jul 2017 23:48:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1501224492; cv=none; d=google.com; s=arc-20160816; b=ZfhM1Xamncw9P8pgobKztAFpdk+qATpu4fwAteOOpu5JZvuXIuCn/cQdFJhaXRWqVn TvYCoAY/8mhnPv1drJBwMRzkavdXEc4ROI8hYwDldPznnhTDEMUVJa8+NkLE0DDhtWYI E/0HGefcgntO2KNxhxXg2P7BQPf7ghd23Gbtfy494qHsbNgcWPS74v8TuT9Pp/z++wTt VUUFh2ELCos0YMU0CxPskVOlh0moVNerYW5L3A+BU1utpOU7y6hI7/vOe8SGXwiq8zlI bq8UO+A8T8FTmM1qCnNHBGowmMTgjF7/57hR/VCTc9QheOk9Dc0YclifQyDPv+aFb+OI a04A== 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=pXPIZ8LBfCHSI9VidJD+t0/ReHxsMA1X/FM5BhkTpxA=; b=ETV3n/ooecSPma5RWIDqFTuZqdjxaVwk+fv9R0t1o1K5lK6g8XPU/ADo6wuT84YZ6T IW8rV4SwUexgQ65E4PwSu6WRWtyJxRNdcYZdwb6QAUbHV+LDaPofl4ItipXPA9ewKNmC Z876ZisD8QBETGLZgm//5PpTK37aAT9xJGVigN50mUn8CYxIbIWZ6AKWDhKzIJSg65zu CBtwe/f6dXocRPGv7Ukr9z964U/gZXCaBaNgYyM+GH0w4x87gXu1kV2LQ2IqrWe4o6a9 pRVPckNJMylelpSDtkgjxSe2vqeyYLkoMCUaj+HptmAlFOYWwCszCTH1j8KSnXErwQv0 /9nw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=MxppJz84; 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 b85si9853717pfc.659.2017.07.27.23.48.11; Thu, 27 Jul 2017 23:48:12 -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 header.b=MxppJz84; 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 S1751748AbdG1GsH (ORCPT + 26 others); Fri, 28 Jul 2017 02:48:07 -0400 Received: from mail-pg0-f50.google.com ([74.125.83.50]:38742 "EHLO mail-pg0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751787AbdG1Grw (ORCPT ); Fri, 28 Jul 2017 02:47:52 -0400 Received: by mail-pg0-f50.google.com with SMTP id k190so41965704pgk.5 for ; Thu, 27 Jul 2017 23:47:52 -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=pXPIZ8LBfCHSI9VidJD+t0/ReHxsMA1X/FM5BhkTpxA=; b=MxppJz84Fczac+cr87LTQzU0hvy9QpTPdU6njeXX/sIheo9ZOsafJNru+BTQqk3mHx 3YNNlKaoBBjzxxvdr9cS9ExyGASx/HBpD0c5Bed+jkMpLUtNHKI7JS47dmrmjry6l/jD MpF8h6KFbTaRA5rbQJw+vR24VOxzXSQkMRa0k= 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=pXPIZ8LBfCHSI9VidJD+t0/ReHxsMA1X/FM5BhkTpxA=; b=EiDxMudLe1QFSatdLZbdC9qa6XV9Nm9HtsNpSaNGV0kmlqmFK06dsSdihZoXv0FN58 d6JYUq/7uuqa87wBPdOtYvOK619Hn6rHgv8CBORTnOUbcUb17yBye4Q/MWno3ah5Fss/ j7M+nEiSjEmBbChM1prcp0mCAxVZ75pmz8tbC+403m8u+QaWSlwfZ+LZPZu0MqCpykU+ aOLPWn5ABmpt2JaV1z2eDRE9o8VvLQsnuG3uNurdPoid3XFVBkNPU0NK6quzcqEXWkTB WDkmkOUBW+IoEJM5tL85DJhWYOBZX7HbzEkLN/HGKc/Rt3JP2lOdSRdE6T4avLs404D0 7OLA== X-Gm-Message-State: AIVw110QcDRxwuUdTcOkpt4VnSn/FdRH1NzfcKzWGAx/mOpuV0nddRSB nYnUrwQX2uicI7zx X-Received: by 10.98.155.133 with SMTP id e5mr6520573pfk.186.1501224471669; Thu, 27 Jul 2017 23:47:51 -0700 (PDT) Received: from localhost ([122.171.79.89]) by smtp.gmail.com with ESMTPSA id l17sm39411221pfk.146.2017.07.27.23.47.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jul 2017 23:47:51 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki , Peter Zijlstra , Viresh Kumar Cc: linux-pm@vger.kernel.org, Vincent Guittot , smuckle.linux@gmail.com, juri.lelli@arm.com, Morten.Rasmussen@arm.com, patrick.bellasi@arm.com, eas-dev@lists.linaro.org, skannan@codeaurora.org, joelaf@google.com, linux-kernel@vger.kernel.org Subject: [PATCH V5 2/2] cpufreq: Process remote callbacks from any CPU if the platform permits Date: Fri, 28 Jul 2017 12:16:39 +0530 Message-Id: X-Mailer: git-send-email 2.13.0.71.gd7076ec9c9cb 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 On many platforms, CPUs can do DVFS across cpufreq policies. i.e CPU from policy-A can change frequency of CPUs belonging to policy-B. This is quite common in case of ARM platforms where we don't configure any per-cpu register. Add a flag to identify such platforms and update cpufreq_can_do_remote_dvfs() to allow remote callbacks if this flag is set. Also enable the flag for cpufreq-dt driver which is used only on ARM platforms currently. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq-dt.c | 1 + include/linux/cpufreq.h | 18 ++++++++++++++++-- 2 files changed, 17 insertions(+), 2 deletions(-) -- 2.13.0.71.gd7076ec9c9cb diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c index fef3c2160691..d83ab94d041a 100644 --- a/drivers/cpufreq/cpufreq-dt.c +++ b/drivers/cpufreq/cpufreq-dt.c @@ -274,6 +274,7 @@ static int cpufreq_init(struct cpufreq_policy *policy) transition_latency = CPUFREQ_ETERNAL; policy->cpuinfo.transition_latency = transition_latency; + policy->dvfs_possible_from_any_cpu = true; return 0; diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index b3b6e8203e82..227cd0f13300 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -127,6 +127,15 @@ struct cpufreq_policy { */ unsigned int transition_delay_us; + /* + * Remote DVFS flag (Not added to the driver structure as we don't want + * to access another structure from scheduler hotpath). + * + * Should be set if CPUs can do DVFS on behalf of other CPUs from + * different cpufreq policies. + */ + bool dvfs_possible_from_any_cpu; + /* Cached frequency lookup from cpufreq_driver_resolve_freq. */ unsigned int cached_target_freq; int cached_resolved_idx; @@ -564,8 +573,13 @@ struct governor_attr { static inline bool cpufreq_can_do_remote_dvfs(struct cpufreq_policy *policy) { - /* Allow remote callbacks only on the CPUs sharing cpufreq policy */ - if (cpumask_test_cpu(smp_processor_id(), policy->cpus)) + /* + * Allow remote callbacks if: + * - dvfs_possible_from_any_cpu flag is set + * - the local and remote CPUs share cpufreq policy + */ + if (policy->dvfs_possible_from_any_cpu || + cpumask_test_cpu(smp_processor_id(), policy->cpus)) return true; return false;