From patchwork Thu Nov 30 11:47:18 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Bellasi X-Patchwork-Id: 120143 Delivered-To: patch@linaro.org Received: by 10.140.22.227 with SMTP id 90csp558722qgn; Thu, 30 Nov 2017 03:47:56 -0800 (PST) X-Google-Smtp-Source: AGs4zMYNZkLePc1HINxvIY0FJ3c99nzpVfvWEVFq7x5kStnImAqiyzd9ZnEoP2VJNpNaxQuigtZ9 X-Received: by 10.99.96.147 with SMTP id u141mr2156421pgb.342.1512042475961; Thu, 30 Nov 2017 03:47:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512042475; cv=none; d=google.com; s=arc-20160816; b=v0ct/6c2ej2lkgPZkix6AbHFJWk0NOmVyONsg0EP2G61REyVJ/V9dZCHB0D7x7UlJG OMN0rPsEDO/ca+aLjN1oVMiHEtf4Va6EtwB/eKAlaBu2sRjn4sOpgUGSPRQJ8nDz4fhl s829OjVoQYf96VEjbSYufbBiNPUKhuGBCWEFqMA3QhG4GTULBL8oDD3tRJGmg/vk2foi 9JhgPcAQNj7mkUaW+lZrT6qGFkIjFQfW4HXgha6sbKL43pe0c19oQolVxlxoQsaoQlvE vRZSWjPAhPCm6gaKkG5myKjt7mmJcWWgQBYBLnyWuWQ4/RloK3fFYq0fFY4D7pEe/iM1 QNxg== 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=N8OrKQzHRfoDqUnDAv/zbIktL1JUHgthctBSuzfXP7E=; b=aptR9UQjCAOIqkLdHbAoh8wX5NH6qGObtHrtnBU9cYbgWrTWopyoCmneUBoUVQHHu6 JkUHL1oxDdB7whdYIv7KAFwZRUkJHXR4rVnqWK3ypzSzeJ5DLPU26fir9sbGfuKWOffw Csu2z/JTkeWSnLuYZG9jYxXVvrNjIcaz8aT61h8n/Byqk6DJTs+hQ7u3m1Enev34DlMo 2+mwVQpVJsc9lynd+3Y9GKTdSOwHxt43GcFNs6zG9V8htRYbenOI3+6qa+5aKCz8mh9B QFlFo+2kJO9a1uT6jehs/xMjuXEO2Du2HRLJxtV4DTjmuDW4mBc8U1LyOytAWkhE/nRq 2U4w== 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 d3si2949363pll.329.2017.11.30.03.47.55; Thu, 30 Nov 2017 03:47:55 -0800 (PST) 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 S1752494AbdK3Lrx (ORCPT + 26 others); Thu, 30 Nov 2017 06:47:53 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:51258 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751513AbdK3Lru (ORCPT ); Thu, 30 Nov 2017 06:47:50 -0500 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 00CDF1596; Thu, 30 Nov 2017 03:47:50 -0800 (PST) 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 BEA883F236; Thu, 30 Nov 2017 03:47:47 -0800 (PST) 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 , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes Subject: [PATCH v3 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter Date: Thu, 30 Nov 2017 11:47:18 +0000 Message-Id: <20171130114723.29210-2-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.14.1 In-Reply-To: <20171130114723.29210-1-patrick.bellasi@arm.com> References: <20171130114723.29210-1-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(); for RT/DL classes this corresponds to the SCHED_CPUFREQ_{RT/DL} flags always being set. When multiple CPUs share the same frequency domain it might happen that a CPU which executed an 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 clears the SCHED_CPUFREQ_{RT/DL} flag, or the IDLE CPUs gets ignored after TICK_NSEC [ns] 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 Reviewed-by: Dietmar Eggemann 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 v2: - use cpufreq_update_util() instead of cpufreq_update_this_cpu() - rebased on v4.15-rc1 Changes from v1: - added "unlikely()" around the statement (SteveR) Change-Id: I1192ca9a3acb767cb3a745967a7a23a17e1af7b7 --- include/linux/sched/cpufreq.h | 1 + kernel/sched/cpufreq_schedutil.c | 7 +++++++ kernel/sched/idle_task.c | 4 ++++ 3 files changed, 12 insertions(+) -- 2.14.1 diff --git a/include/linux/sched/cpufreq.h b/include/linux/sched/cpufreq.h index d1ad3d825561..bb5f778db023 100644 --- a/include/linux/sched/cpufreq.h +++ b/include/linux/sched/cpufreq.h @@ -11,6 +11,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 2f52ec0f1539..67339ccb5595 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -347,6 +347,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); @@ -361,6 +367,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 d518664cce4f..6e8ae2aa7a13 100644 --- a/kernel/sched/idle_task.c +++ b/kernel/sched/idle_task.c @@ -30,6 +30,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_util(rq, SCHED_CPUFREQ_IDLE); + return rq->idle; }