From patchwork Wed Jul 26 09:22:31 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 108738 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp572851qge; Wed, 26 Jul 2017 02:23:31 -0700 (PDT) X-Received: by 10.101.89.69 with SMTP id g5mr292351pgu.114.1501061011435; Wed, 26 Jul 2017 02:23:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1501061011; cv=none; d=google.com; s=arc-20160816; b=nuccCPhZPC+DCl9JyXwaqjlFzIPL70JfqQB1Lk2PwoYmOiO3gDwANeFna02VOdntVF Vh5ENVowH5nshzZnfqqLjokP1/B6SlD61wdM6Q1cUx9iVvm82S9lYLGu678W7yx+ZcyH DyHjFR1R39us9KvIM9IE0tL8T9QcruAid60NxvlgbD8+kGxYf5KKxtE42xCRMSk0e/8Q txktbMJcBG8AACI61uJJPk0iXH4dQQaZv9jSbjT4FjQbL9MhsBU6UHqkLTFmuZ/amhPE c5Ez9nEeee5VngjADt51Bd4CJRsTkvQZ7E+CFudFZ0SV+8MSrUnnwfWB6dQO31ArpuiP L7iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=6bn/1rlEh4xwNN03pzd0jrmr2mdIQjbGAiDmgdR6SWs=; b=jClvQ6zHLujbp1acYJITM7jgu4O7T7OfQEuO9btvjPuRTi9ANECg58mssdGCfHnKCD V2gWEQ5jpvBP81TeU2pPgVOg4OLq3727FPbjfQUvmVPLGvTNgq48N3j3TXlV0kyOOQqs OAhjg/3FTgIY/4X4KzXV79hHYnwUv2iL4rRaiE9J7wB276/41/SxboKdd9DekjBBlA/J O5jgQJaBO4vYhQfeH4PKSGQHyZUgtYW+20Hc/0wbsMblV5Zf7ocJdMncoRbi62MySdX0 5tQ19mjybVVTdUlx/wKt8VqBGbYqGPrwSrD0U782xAPPL2jGK07kcHqqZfm27DztWhhF gKfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=SbBmsr5Z; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w23si9316745pfj.173.2017.07.26.02.23.31; Wed, 26 Jul 2017 02:23:31 -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=pass header.i=@linaro.org header.b=SbBmsr5Z; 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 S1751024AbdGZJXa (ORCPT + 13 others); Wed, 26 Jul 2017 05:23:30 -0400 Received: from mail-pg0-f44.google.com ([74.125.83.44]:36883 "EHLO mail-pg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750989AbdGZJX2 (ORCPT ); Wed, 26 Jul 2017 05:23:28 -0400 Received: by mail-pg0-f44.google.com with SMTP id y129so81777101pgy.4 for ; Wed, 26 Jul 2017 02:23:28 -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; bh=6bn/1rlEh4xwNN03pzd0jrmr2mdIQjbGAiDmgdR6SWs=; b=SbBmsr5Z8neZloC0Ju0JciUVq0aRB1Y0bavZail4dCl//hTd3xfNlzku4rAd477zPV pC4fJXGOad/GFtzW25c+j4zT3yxSO0E+FFGvYL7tU89CG+1nViBPdmWr7H9F4JvDiUrK FGgcu23XIxsf+o8ilJdJTy0aJgXPd59XERanI= 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=6bn/1rlEh4xwNN03pzd0jrmr2mdIQjbGAiDmgdR6SWs=; b=UcOr8Ow9OETz1/gy1oQ9H3rZ/3NoBz5xEC9/tFinIh+567kmmMIEB88uSlEvDrAfmg MlPRynYEMD5VM3FmWPXKrqGYdupjmKyQypYk0DQpmhpgYtI6nwE7yryN4ttyxzHoqZP+ mnjgC3/vUzS+cqOyGjoLD3RQWvBFgQNU0ZN68iuDbtHdvwZ4LT0//YMmXflxHMGEPUNf P60aYaWJz+xz7igLOFOLORfj5UuG0KLbikHVvznVEtsxURp6+IaJoGXgYq45dvRwOBBM ffyHH/072pxj37UqEHAWNjO6RPt+rhJIG2g8QKKyFoSGtb2qZDitBvlYnx/lET6sU6jD 7RdQ== X-Gm-Message-State: AIVw113kyl198H0YPa6bsrEqLhy+fyc+3uP/00TE4i5EDbe4Ct1rGsXN oPfZpoE/Kb6SLpls X-Received: by 10.84.169.227 with SMTP id h90mr284436plb.145.1501061008369; Wed, 26 Jul 2017 02:23:28 -0700 (PDT) Received: from localhost ([122.171.79.89]) by smtp.gmail.com with ESMTPSA id f2sm27306362pgc.17.2017.07.26.02.23.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jul 2017 02:23:27 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki Cc: Viresh Kumar , 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, Ingo Molnar , Len Brown , linux-kernel@vger.kernel.org, Peter Zijlstra , Srinivas Pandruvada Subject: [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks Date: Wed, 26 Jul 2017 14:52:31 +0530 Message-Id: X-Mailer: git-send-email 2.13.0.71.gd7076ec9c9cb Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Hi, I had some IRC discussions with Peter and V4 is based on his feedback. Here is the diff between V3 and V4: -------------------------8<------------------------- With Android UI and benchmarks the latency of cpufreq response to certain scheduling events can become very critical. Currently, callbacks into schedutil 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 schedutil 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 new tasks should receive maximum demand initially, this should result in CPU0 increasing frequency immediately. Because of the above mentioned limitation though this does not occur. This is verified using ftrace with the sample [1] application. Maybe the ideal solution is to always allow remote callbacks but that has its own challenges: o There is no protection required for single CPU per policy case today, and adding any kind of locking there, to supply remote callbacks, isn't really a good idea. o If is local CPU isn't part of the same cpufreq policy as the target CPU, then we wouldn't be able to do fast switching at all and have to use some kind of bottom half to schedule work on the target CPU to do real switching. That may be overkill as well. And so this series only allows remote callbacks for target CPUs that share the cpufreq policy with the local CPU. This series 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 patchset 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 maximum demand initially, and should take the CPU to higher OPPs. - And the target CPU doesn't call into schedutil until the next tick. V3->V4: - Respect iowait boost flag and util updates for the all remote callbacks. - Minor updates in commit log of 2/3. V2->V3: - Rearranged/merged patches as suggested by Rafael (looks much better now) - Also handle new hook added to intel-pstate driver. - The final code remains the same as V2, except for the above hook. V1->V2: - Don't support remote callbacks for unshared cpufreq policies. - Don't support remote callbacks where local CPU isn't part of the target CPU's cpufreq policy. - Dropped dvfs_possible_from_any_cpu flag. -- viresh Viresh Kumar (3): sched: cpufreq: Allow remote cpufreq callbacks cpufreq: schedutil: Process remote callback for shared policies cpufreq: governor: Process remote callback for shared policies drivers/cpufreq/cpufreq_governor.c | 4 ++++ drivers/cpufreq/intel_pstate.c | 8 ++++++++ include/linux/sched/cpufreq.h | 1 + kernel/sched/cpufreq.c | 1 + kernel/sched/cpufreq_schedutil.c | 14 +++++++++----- kernel/sched/deadline.c | 2 +- kernel/sched/fair.c | 8 +++++--- kernel/sched/rt.c | 2 +- kernel/sched/sched.h | 10 ++-------- 9 files changed, 32 insertions(+), 18 deletions(-) -- 2.13.0.71.gd7076ec9c9cb Reviewed-by: Joel Fernandes diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index d64754fb912e..df9aa1ee53ff 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -79,6 +79,10 @@ static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 time) s64 delta_ns; bool update; + /* Allow remote callbacks only on the CPUs sharing cpufreq policy */ + if (!cpumask_test_cpu(smp_processor_id(), sg_policy->policy->cpus)) + return false; + if (sg_policy->work_in_progress) return false; @@ -225,10 +229,6 @@ static void sugov_update_single(struct update_util_data *hook, u64 time, unsigned int next_f; bool busy; - /* Remote callbacks aren't allowed for policies which aren't shared */ - if (smp_processor_id() != hook->cpu) - return; - sugov_set_iowait_boost(sg_cpu, time, flags); sg_cpu->last_update = time; @@ -298,14 +298,9 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time, { struct sugov_cpu *sg_cpu = container_of(hook, struct sugov_cpu, update_util); struct sugov_policy *sg_policy = sg_cpu->sg_policy; - struct cpufreq_policy *policy = sg_policy->policy; unsigned long util, max; unsigned int next_f; - /* Allow remote callbacks only on the CPUs sharing cpufreq policy */ - if (!cpumask_test_cpu(smp_processor_id(), policy->cpus)) - return; - sugov_get_util(&util, &max, hook->cpu); raw_spin_lock(&sg_policy->update_lock);