From patchwork Tue Jul 4 17:34:06 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Bellasi X-Patchwork-Id: 107004 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp1251003qge; Tue, 4 Jul 2017 10:34:41 -0700 (PDT) X-Received: by 10.98.21.9 with SMTP id 9mr16285156pfv.234.1499189681225; Tue, 04 Jul 2017 10:34:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1499189681; cv=none; d=google.com; s=arc-20160816; b=uxERStpVWpwPFyEbFLdm2QUmFRn5uctUAImb2XUVDq5fqDrhzTUGn975V3hYdn3ZvD cEsP6amQe5F2CDcV0idJX6zWeAA7T0+3SV84ouPXtetDFok72QY6In85gb2Gru9cZ/ar vyUm5Zbvo12JT7FhxVIxTceN3s4EjcQsWJEwc5qAjjjbbRwb4NUKUZnD3e7wYY93jDfw a9286r3GQMrSVo2GaqAuJ1kQVQ0wJnwIcG7XzYrdM/ufOYjBUCb6VNFr6cP+QaJmh5jm wE+tdjHjNU2IPYqHu7cuLQPhN1EZJQx06qwpGuvli3Id1YDPn/qEyvbHz0llUF6pnEAW NS9Q== 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=ghGBEy5shP1bOgvtQRBTwgTUZlZTbkHOPjkcKVBEJYU=; b=ShH6qDp7o53bqNhS+GvpSmayyJ66H9YMibPmvYlj7NpvxWHnpni77KvamLuypYXTQW jAD7Woj2QQyhbZP7MCvj7LCwQ1ZN+T/J9KzXfNBZ3adQg+6vO8CKIEy1xT6VaN+gz7xd pgYE/T1WD04fCQltvUwzkb7TN+AFD6t0YXn/Zfi4QdxwvQi0of/Bpwd2pjUiMZG6oCDU RmnehFqe4ufzGEvsPdD4JiiVQ6imbm+Rpn8ESQJuM+x00ftyFNmKpljgzYJhKu0jI7uo eWTfKKHIN9lIBawF/k25Jzu/mQLibzsuuaJq7fphNc+/h0+fLNf9pPHePv+1EfraxKRm Q4jA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k62si15022999pgk.580.2017.07.04.10.34.40; Tue, 04 Jul 2017 10:34:41 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752224AbdGDRe2 (ORCPT + 25 others); Tue, 4 Jul 2017 13:34:28 -0400 Received: from foss.arm.com ([217.140.101.70]:48100 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751982AbdGDReZ (ORCPT ); Tue, 4 Jul 2017 13:34:25 -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 362C915A2; Tue, 4 Jul 2017 10:34:25 -0700 (PDT) Received: from e110439-lin.cambridge.arm.com (e110439-lin.cambridge.arm.com [10.1.210.68]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 130FF3F41F; Tue, 4 Jul 2017 10:34:22 -0700 (PDT) From: Patrick Bellasi To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Juri Lelli , Joel Fernandes , Andres Oportus , Todd Kjos , Morten Rasmussen , Dietmar Eggemann Subject: [PATCH v2 1/6] cpufreq: schedutil: ignore sugov kthreads Date: Tue, 4 Jul 2017 18:34:06 +0100 Message-Id: <1499189651-18797-2-git-send-email-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> References: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In system where multiple CPUs shares the same frequency domain a small workload on a CPU can still be subject to frequency spikes, generated by the activation of the sugov's kthread. Since the sugov kthread is a special RT task, which goal is just that to activate a frequency transition, it does not make sense for it to bias the schedutil's frequency selection policy. This patch exploits the information related to the current task to silently ignore cpufreq_update_this_cpu() calls, coming from the RT scheduler, while the sugov kthread is running. Signed-off-by: Patrick Bellasi Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Rafael J. Wysocki Cc: Viresh Kumar Cc: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org --- Changes from v1: - move check before policy spinlock (JuriL) --- kernel/sched/cpufreq_schedutil.c | 8 ++++++++ 1 file changed, 8 insertions(+) -- 2.7.4 diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index c982dd0..eaba6d6 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -218,6 +218,10 @@ static void sugov_update_single(struct update_util_data *hook, u64 time, unsigned int next_f; bool busy; + /* Skip updates generated by sugov kthreads */ + if (unlikely(current == sg_policy->thread)) + return; + sugov_set_iowait_boost(sg_cpu, time, flags); sg_cpu->last_update = time; @@ -290,6 +294,10 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time, unsigned long util, max; unsigned int next_f; + /* Skip updates generated by sugov kthreads */ + if (unlikely(current == sg_policy->thread)) + return; + sugov_get_util(&util, &max); raw_spin_lock(&sg_policy->update_lock); From patchwork Tue Jul 4 17:34:07 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Bellasi X-Patchwork-Id: 107006 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp1251182qge; Tue, 4 Jul 2017 10:34:52 -0700 (PDT) X-Received: by 10.84.172.1 with SMTP id m1mr17407435plb.174.1499189692740; Tue, 04 Jul 2017 10:34:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1499189692; cv=none; d=google.com; s=arc-20160816; b=rY1M4IpBFpe4p9m2IllxmvtsYDsxCDFlxysa3q9QDBNlVaQFnJjA/D23QK3wxF+Rby yhGaImCVEiMwgyEFXto1lzIr4youDoFdPN3oQSXLBRGTCjIijHBvP9R7h2w8JlpqIM+C JWiwlUeJw+lA3cRFZTlDxLyCRODz+sS1WO3yCYOuSnYCaAVqSszYM9DL3EW8brEcph5P yqKtORxsrmvsXvQUev+U35/bZG1WQBSsv8T7oiJTWg7ucFV7olk+pjqcQgxiYu7T4En9 tp82CSOQVxx2prgBBNAOqKRQVnIDHF7pAIm/v73RjroSOZbLBcOWNaGgC1N4Uexubkg2 9oCw== 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=vSzBFHQFrPsGsWM4Zsdeb2+F2qN5pULJnXfO/x8dnXg=; b=G9Yac7DyTifDvQLjFcxyP6lw2IdUEK1unkvJFBnAmNBXaCmoYDAO24lx9mwkRTWd6E pmmh17JFvXEOW0SUs0zlnqN8Gc+U1bVMD9c3/Mkqf/KqSdZdmygWWpYjB8HNxcbsWg1w 57jO6v3kIxgz84OuBVqqzwxhzqMiS15FNLq8KgaTDjZWBYm7AxNMsLT8nS3X1DzJBaJF /QCEtDxcF7LrEaQo967TecY1arqntn15MQRQ+jUkeCc+JC8QYr8ji76urm7dXercGljo AOzg/y/7cBV5S0/jLOUJR/cUGtyuCnY4fxJ+gomkyH+Hz43I5XaiAFoQ3jHgyWa6MGZd 8bgA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s1si16073408plj.439.2017.07.04.10.34.52; Tue, 04 Jul 2017 10:34:52 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752380AbdGDRel (ORCPT + 25 others); Tue, 4 Jul 2017 13:34:41 -0400 Received: from foss.arm.com ([217.140.101.70]:48108 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752256AbdGDRei (ORCPT ); Tue, 4 Jul 2017 13:34:38 -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 923D31596; Tue, 4 Jul 2017 10:34:27 -0700 (PDT) Received: from e110439-lin.cambridge.arm.com (e110439-lin.cambridge.arm.com [10.1.210.68]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 72D333F41F; Tue, 4 Jul 2017 10:34:25 -0700 (PDT) From: Patrick Bellasi To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Juri Lelli , Joel Fernandes , Andres Oportus , Todd Kjos , Morten Rasmussen , Dietmar Eggemann Subject: [PATCH v2 2/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter Date: Tue, 4 Jul 2017 18:34:07 +0100 Message-Id: <1499189651-18797-3-git-send-email-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> References: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently, sg_cpu's flags are set to the value defined by the last call of the cpufreq_update_util()/cpufreq_update_this_cpu(); for RT/DL classes this corresponds to the SCHED_CPUFREQ_{RT/DL} flags always being set. When multiple CPU shares the same frequency domain it might happen that a CPU which executed a RT task, right before entering IDLE, has one of the SCHED_CPUFREQ_RT_DL flags set, permanently, until it exits IDLE. Although such an idle CPU is _going to be_ ignored by the sugov_next_freq_shared(): 1. this kind of "useless RT requests" are ignored only if more then TICK_NSEC have elapsed since the last update 2. we can still potentially trigger an already too late switch to MAX, which starts also a new throttling interval 3. the internal state machine is not consistent with what the scheduler knows, i.e. the CPU is now actually idle Thus, in sugov_next_freq_shared(), where utilisation and flags are aggregated across all the CPUs of a frequency domain, it can turn out that all the CPUs of that domain can run unnecessary at the maximum OPP until another event happens in the idle CPU, which eventually clear the SCHED_CPUFREQ_{RT/DL} flag, or the IDLE CPUs gets ignored after TICK_NSEC since the CPU entering IDLE. Such a behaviour can harm the energy efficiency of systems where RT workloads are not so frequent and other CPUs in the same frequency domain are running small utilisation workloads, which is a quite common scenario in mobile embedded systems. This patch proposes a solution which is aligned with the current principle to update the flags each time a scheduling event happens. The scheduling of the idle_task on a CPU is considered one of such meaningful events. That's why when the idle_task is selected for execution we poke the schedutil policy to reset the flags for that CPU. No frequency transitions are activated at that point, which is fair in case the RT workload should come back in the future. However, this still allows other CPUs in the same frequency domain to scale down the frequency in case that should be possible. Signed-off-by: Patrick Bellasi Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Rafael J. Wysocki Cc: Viresh Kumar Cc: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org --- Changes from v1: - added "unlikely()" around the statement (SteveR) --- include/linux/sched/cpufreq.h | 1 + kernel/sched/cpufreq_schedutil.c | 7 +++++++ kernel/sched/idle_task.c | 4 ++++ 3 files changed, 12 insertions(+) -- 2.7.4 diff --git a/include/linux/sched/cpufreq.h b/include/linux/sched/cpufreq.h index d2be2cc..36ac8d2 100644 --- a/include/linux/sched/cpufreq.h +++ b/include/linux/sched/cpufreq.h @@ -10,6 +10,7 @@ #define SCHED_CPUFREQ_RT (1U << 0) #define SCHED_CPUFREQ_DL (1U << 1) #define SCHED_CPUFREQ_IOWAIT (1U << 2) +#define SCHED_CPUFREQ_IDLE (1U << 3) #define SCHED_CPUFREQ_RT_DL (SCHED_CPUFREQ_RT | SCHED_CPUFREQ_DL) diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index eaba6d6..004ae18 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -304,6 +304,12 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time, sg_cpu->util = util; sg_cpu->max = max; + + /* CPU is entering IDLE, reset flags without triggering an update */ + if (unlikely(flags & SCHED_CPUFREQ_IDLE)) { + sg_cpu->flags = 0; + goto done; + } sg_cpu->flags = flags; sugov_set_iowait_boost(sg_cpu, time, flags); @@ -318,6 +324,7 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time, sugov_update_commit(sg_policy, time, next_f); } +done: raw_spin_unlock(&sg_policy->update_lock); } diff --git a/kernel/sched/idle_task.c b/kernel/sched/idle_task.c index 0c00172..a844c91 100644 --- a/kernel/sched/idle_task.c +++ b/kernel/sched/idle_task.c @@ -29,6 +29,10 @@ pick_next_task_idle(struct rq *rq, struct task_struct *prev, struct rq_flags *rf put_prev_task(rq, prev); update_idle_core(rq); schedstat_inc(rq->sched_goidle); + + /* kick cpufreq (see the comment in kernel/sched/sched.h). */ + cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_IDLE); + return rq->idle; } From patchwork Tue Jul 4 17:34:08 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Bellasi X-Patchwork-Id: 107005 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp1251012qge; Tue, 4 Jul 2017 10:34:42 -0700 (PDT) X-Received: by 10.98.58.11 with SMTP id h11mr16243430pfa.148.1499189681909; Tue, 04 Jul 2017 10:34:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1499189681; cv=none; d=google.com; s=arc-20160816; b=PQxwfrTQUl1rtSgqeRMOx8i+u3ZeOFBz/UmxdqKVWbBpvLicO50N2QEZe1RdxIViz+ tkDsPLu+y9deEiDwnwu5c4QT916snjtcg2+1jIrKXOWkWtkx02waO9IBcDkvCYp6YGw8 7tU6PoG6bsKMFt6+e8CFqH8QWD/l+pOFy3BAjpyJ7CjiOm3HoLPFgcIS1OBtmJebefzU qyYmpDDD3vz8JpGcv6bD/eZIG6CJ76W6ZVaTvbUl3Ylt44aWxaK4V8AD2MPgk+RjzZ/0 ZibyzagfP27Kl3+27Le1OM44yHmYzWMJiMCK82kXQjSme9NOqPcvkw07ccG4MuJJhS0c UGog== 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=3BO8E29//Ulfjy+U8V7RQFn3cWqQ9IQXQ0ATCI3kUL4=; b=IGAY6w5AqRMzgfIgYYyH4/1dV12iN3iKDCRKQumRjskGC+2uMsEPxNf9cSRiQhLUBk UAyS+hwM6frCVFp6bJOBMABM7dw8dBjGzPkMvMLBMDRZqgJbvqoeZA4ZZ8FINkXFyBL3 1oDHTt+1CD7hvH5ygym8DeMYGSP99CPsj1RcpaF5GO10zEcnEg5r+33k3nPfZ4oqp2Rq bbQ/iEbjy5hlECb9woWxo+qUkEwSxLe+IYr4q6mYLTumXWFu+RZrB0JFrh/XiZ/5EC4d j3mU/f6skruF+I0KKJjxdVHGMUqd5HXTXX7Rb0fuMujdxPNpES1+B4+U2A9PCqp/PuQR D+Vw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k62si15022999pgk.580.2017.07.04.10.34.41; Tue, 04 Jul 2017 10:34:41 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752292AbdGDReh (ORCPT + 25 others); Tue, 4 Jul 2017 13:34:37 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:48138 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752248AbdGDRef (ORCPT ); Tue, 4 Jul 2017 13:34:35 -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 2187815BE; Tue, 4 Jul 2017 10:34:30 -0700 (PDT) Received: from e110439-lin.cambridge.arm.com (e110439-lin.cambridge.arm.com [10.1.210.68]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id D02243F41F; Tue, 4 Jul 2017 10:34:27 -0700 (PDT) From: Patrick Bellasi To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Juri Lelli , Joel Fernandes , Andres Oportus , Todd Kjos , Morten Rasmussen , Dietmar Eggemann , Steve Muckle Subject: [PATCH v2 3/6] cpufreq: schedutil: ensure max frequency while running RT/DL tasks Date: Tue, 4 Jul 2017 18:34:08 +0100 Message-Id: <1499189651-18797-4-git-send-email-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> References: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The policy in use for RT/DL tasks sets the maximum frequency when a task in these classes calls for a cpufreq_update_this_cpu(). However, the current implementation might cause a frequency drop while a RT/DL task is still running, just because for example a FAIR task wakes up and it's enqueued in the same CPU. This issue is due to the sg_cpu's flags being overwritten at each call of sugov_update_*. Thus, the wakeup of a FAIR task resets the flags and can trigger a frequency update thus affecting the currently running RT/DL task. This can be fixed, in shared frequency domains, by ORing (instead of overwriting) the new flag before triggering a frequency update. This grants to stay at least at the frequency requested by the RT/DL class, which is the maximum one for the time being. This patch does the flags aggregation in the schedutil governor, where it's easy to verify if we currently have RT/DL workload on a CPU. This approach is aligned with the current schedutil API design where the core scheduler does not interact directly with schedutil, while instead are the scheduling classes which call directly into the policy via cpufreq_update_{util,this_cpu}. Thus, it makes more sense to have flags aggregation in the schedutil code instead of the core scheduler. Signed-off-by: Patrick Bellasi Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Rafael J. Wysocki Cc: Viresh Kumar Cc: Steve Muckle Cc: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org --- Changes from v1: - use "current" to check for RT/DL tasks (PeterZ) --- kernel/sched/cpufreq_schedutil.c | 34 +++++++++++++++++++++++++++------- 1 file changed, 27 insertions(+), 7 deletions(-) -- 2.7.4 diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index 004ae18..98704d8 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -216,6 +216,7 @@ static void sugov_update_single(struct update_util_data *hook, u64 time, struct cpufreq_policy *policy = sg_policy->policy; unsigned long util, max; unsigned int next_f; + bool rt_mode; bool busy; /* Skip updates generated by sugov kthreads */ @@ -230,7 +231,15 @@ static void sugov_update_single(struct update_util_data *hook, u64 time, busy = sugov_cpu_is_busy(sg_cpu); - if (flags & SCHED_CPUFREQ_RT_DL) { + /* + * While RT/DL tasks are running we do not want FAIR tasks to + * overvrite this CPU's flags, still we can update utilization and + * frequency (if required/possible) to be fair with these tasks. + */ + rt_mode = task_has_dl_policy(current) || + task_has_rt_policy(current) || + (flags & SCHED_CPUFREQ_RT_DL); + if (rt_mode) { next_f = policy->cpuinfo.max_freq; } else { sugov_get_util(&util, &max); @@ -293,6 +302,7 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time, struct sugov_policy *sg_policy = sg_cpu->sg_policy; unsigned long util, max; unsigned int next_f; + bool rt_mode; /* Skip updates generated by sugov kthreads */ if (unlikely(current == sg_policy->thread)) @@ -310,17 +320,27 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time, sg_cpu->flags = 0; goto done; } - sg_cpu->flags = flags; + + /* + * While RT/DL tasks are running we do not want FAIR tasks to + * overwrite this CPU's flags, still we can update utilization and + * frequency (if required/possible) to be fair with these tasks. + */ + rt_mode = task_has_dl_policy(current) || + task_has_rt_policy(current) || + (flags & SCHED_CPUFREQ_RT_DL); + if (rt_mode) + sg_cpu->flags |= flags; + else + sg_cpu->flags = flags; sugov_set_iowait_boost(sg_cpu, time, flags); sg_cpu->last_update = time; if (sugov_should_update_freq(sg_policy, time)) { - if (flags & SCHED_CPUFREQ_RT_DL) - next_f = sg_policy->policy->cpuinfo.max_freq; - else - next_f = sugov_next_freq_shared(sg_cpu, time); - + next_f = rt_mode + ? sg_policy->policy->cpuinfo.max_freq + : sugov_next_freq_shared(sg_cpu, time); sugov_update_commit(sg_policy, time, next_f); } From patchwork Tue Jul 4 17:34:09 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Bellasi X-Patchwork-Id: 107009 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp1252114qge; Tue, 4 Jul 2017 10:35:53 -0700 (PDT) X-Received: by 10.84.209.234 with SMTP id y97mr17376807plh.200.1499189753190; Tue, 04 Jul 2017 10:35:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1499189753; cv=none; d=google.com; s=arc-20160816; b=yN4zLPj1McmUMtTsdrG/z+ITG6H0xaDF0w0Dka3Y4kxBl+EnRCOHg98HGtcl+HU3na +pITAuROOSPyNP/9htNF7/P970qP/ewP+BX8DpWGub8Zy7hkULVnPt1sdBvEGqUE8VWT 1GgBrFww5BkZylu435gjQ7mCG5bvxSogvmWe3CyuGEyafxKJaBaw6sBUL1oOJqt9kFpL 0xLmIqFikYhQwXpO6hc9RQAdqIP+I2IwopqzNYCWs6GZKbPH735DbeahNESSWGLu+xLp Dm2Z12vhBNK3cBuBQsYir5NbcBE+/APOU3Zz9VSK3EMCNr7VLhCcbGz2FqpdUDKocqKb V2hQ== 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=2hnwSAtn5CkdP9MPZgNFPN+hJkjjMl8xKhH+gf99q7E=; b=XCnGtP7FgC5d3z0S2DRyzik6mREV9+9g/Ix8T+2VAmnXl6qqa+8cVHuW9FIViY11g5 fA/CEAqgvYJENTLmGJxYceqZjTqyE/SZlG8tZgP+TrSkoVbNVBsTNNddBgT/fESdDxwL 5eRmu6xez3odudqZtR9GBgPiQPCECUvRlB/sGCnTgiXWjBHys9QNsBri64IToH5leIjp lOBkUmxy1Y5l4VvjXIE1YkZCyJnulDBebn5lHSuWq7DNhRytltDAruAiKzxy27V5w/+M Vk9gJrDA77Va60MpkoNy+HZGp/bWWEmTRy7NWl1KAphwP2LbQwV7w6sVw8FojckeZWLv W9Fg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u133si14884536pgb.573.2017.07.04.10.35.52; Tue, 04 Jul 2017 10:35:53 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752341AbdGDRej (ORCPT + 25 others); Tue, 4 Jul 2017 13:34:39 -0400 Received: from foss.arm.com ([217.140.101.70]:48154 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752248AbdGDRei (ORCPT ); Tue, 4 Jul 2017 13:34:38 -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 7D20C164F; Tue, 4 Jul 2017 10:34:32 -0700 (PDT) Received: from e110439-lin.cambridge.arm.com (e110439-lin.cambridge.arm.com [10.1.210.68]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 5E6A03F41F; Tue, 4 Jul 2017 10:34:30 -0700 (PDT) From: Patrick Bellasi To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Juri Lelli , Joel Fernandes , Andres Oportus , Todd Kjos , Morten Rasmussen , Dietmar Eggemann Subject: [PATCH v2 4/6] cpufreq: schedutil: update CFS util only if used Date: Tue, 4 Jul 2017 18:34:09 +0100 Message-Id: <1499189651-18797-5-git-send-email-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> References: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently the utilization of the FAIR class is collected before locking the policy. Although that should not be a big issue for most cases, we also don't really know how much latency there can be between the utilization reading and its usage. Let's get the FAIR utilization right before its usage to be better in sync with the current status of a CPU. Signed-off-by: Patrick Bellasi Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Rafael J. Wysocki Cc: Viresh Kumar Cc: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org --- kernel/sched/cpufreq_schedutil.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 2.7.4 diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index 98704d8..df433f1 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -308,10 +308,9 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time, if (unlikely(current == sg_policy->thread)) return; - sugov_get_util(&util, &max); - raw_spin_lock(&sg_policy->update_lock); + sugov_get_util(&util, &max); sg_cpu->util = util; sg_cpu->max = max; From patchwork Tue Jul 4 17:34:10 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Bellasi X-Patchwork-Id: 107008 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp1251394qge; Tue, 4 Jul 2017 10:35:05 -0700 (PDT) X-Received: by 10.84.176.195 with SMTP id v61mr14553137plb.51.1499189705612; Tue, 04 Jul 2017 10:35:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1499189705; cv=none; d=google.com; s=arc-20160816; b=KKOAVT2syoXOqLp73ZL3rzHmkyeEwjFSkwhBDZHpmPILgn3P+6rL3V96ldwlHiq3mb YwLWDvdP0HjGS8ZLdvPiEPMIGLYyk/EPCcuD6DNZWbQ58l54xTNP6A+DL/bfZzYyZTTa Zw/rti2c9mYYf7GridWmcHtwxNRcU1kMPA/jAFVJAT6dFsE9p8LP4iwWwFNTg+nqDlr1 At/ecUdlHR4x3Eg2t12HzyxX1iYTGlytDJrmiFBdOQOJrDrBW9i6bys5p60GappNBsUv qJyBAr6kD8urO6QRjz0snRY0/kdfKnEBkkc55b/I3gV0GOyimuolJHe08cTYnEWqfio2 gNmQ== 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=dWQKFcZaqoH6SCERjtknIhryjyWtN+o/u7ZU6zmBqbA=; b=i7C/XnygsD9Go4AoyBf9kj5fyTlweAkNFmFiKskTDLq4AfdtpzkUOjnVwSiq/XPqTd Ixo9xGD4Nq0mMg6F6bhNalbEJp4HlOjHf+bUw5kbuRQAHE6pKP+Es4Grw26jKFrDgyk1 xud5jBaXtT9Hq1rHEIsEF5q2ibOt8jeQQ/7QxskVhyKJPanNGyGe6p/QfvJZ9Jv3eIu3 5rQ/AI5M5xqpTkaYn/jjGP4QnSeKdQs+9BMGnYc4y3ivmcnJRGr69L7Nd6JsxLrEDXRp VbxjbcWbEYTrE/CO2IgFFX736dUvBnL2AWSoEnMox9CKvDnhhF0v0hh+OsYaZMl3KFO2 oErQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k69si15278139pfa.293.2017.07.04.10.35.05; Tue, 04 Jul 2017 10:35:05 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752484AbdGDRe6 (ORCPT + 25 others); Tue, 4 Jul 2017 13:34:58 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:48168 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752452AbdGDRez (ORCPT ); Tue, 4 Jul 2017 13:34:55 -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 DE1D6165C; Tue, 4 Jul 2017 10:34:34 -0700 (PDT) Received: from e110439-lin.cambridge.arm.com (e110439-lin.cambridge.arm.com [10.1.210.68]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id B9BF93F41F; Tue, 4 Jul 2017 10:34:32 -0700 (PDT) From: Patrick Bellasi To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Juri Lelli , Joel Fernandes , Andres Oportus , Todd Kjos , Morten Rasmussen , Dietmar Eggemann Subject: [PATCH v2 5/6] sched/rt: fast switch to maximum frequency when RT tasks are scheduled Date: Tue, 4 Jul 2017 18:34:10 +0100 Message-Id: <1499189651-18797-6-git-send-email-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> References: <1499189651-18797-1-git-send-email-patrick.bellasi@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently schedutil updates are triggered for the RT class using a single call place, which is part of the rt::update_curr_rt() used in: - dequeue_task_rt: but it does not make sense to set the schedutil's SCHED_CPUFREQ_RT in case the next task should not be an RT one - put_prev_task_rt: likewise, we set the SCHED_CPUFREQ_RT flag without knowing if required by the next task - pick_next_task_rt: likewise, the schedutil's SCHED_CPUFREQ_RT is set in case the prev task was RT, while we don't yet know if the next will be RT - task_tick_rt: that's the only really useful call, which can ramp up the frequency in case a RT task started its execution without a chance to order a frequency switch (e.g. because of the schedutil ratelimit) Apart from the last call in task_tick_rt, the others are at least useless. Thus, although being a simple solution, not all the call sites of that update_curr_rt() are interesting to trigger a frequency switch as well as some of the most interesting points are not covered by that call. For example, a task set to RT has to wait the next tick to get the frequency boost. This patch fixes these issues by placing explicitly the schedutils update calls in the only sensible places, which are: - when an RT task wakeups and it's enqueued in a CPU - when we actually pick a RT task for execution - at each tick time - when a task is set to be RT Signed-off-by: Patrick Bellasi Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Rafael J. Wysocki Cc: Viresh Kumar Cc: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org --- kernel/sched/rt.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) -- 2.7.4 diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 45caf93..8c25e95 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -969,9 +969,6 @@ static void update_curr_rt(struct rq *rq) if (unlikely((s64)delta_exec <= 0)) return; - /* Kick cpufreq (see the comment in kernel/sched/sched.h). */ - cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT); - schedstat_set(curr->se.statistics.exec_max, max(curr->se.statistics.exec_max, delta_exec)); @@ -1337,6 +1334,9 @@ enqueue_task_rt(struct rq *rq, struct task_struct *p, int flags) if (!task_current(rq, p) && p->nr_cpus_allowed > 1) enqueue_pushable_task(rq, p); + + /* Kick cpufreq (see the comment in kernel/sched/sched.h). */ + cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT); } static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int flags) @@ -1574,6 +1574,9 @@ pick_next_task_rt(struct rq *rq, struct task_struct *prev, struct rq_flags *rf) p = _pick_next_task_rt(rq); + /* Kick cpufreq (see the comment in kernel/sched/sched.h). */ + cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT); + /* The running task is never eligible for pushing */ dequeue_pushable_task(rq, p); @@ -2367,6 +2370,9 @@ static void task_tick_rt(struct rq *rq, struct task_struct *p, int queued) { struct sched_rt_entity *rt_se = &p->rt; + /* Kick cpufreq (see the comment in kernel/sched/sched.h). */ + cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT); + update_curr_rt(rq); watchdog(rq, p); @@ -2402,6 +2408,9 @@ static void set_curr_task_rt(struct rq *rq) p->se.exec_start = rq_clock_task(rq); + /* Kick cpufreq (see the comment in kernel/sched/sched.h). */ + cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT); + /* The running task is never eligible for pushing */ dequeue_pushable_task(rq, p); }