Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp5182046imm; Wed, 12 Sep 2018 02:15:57 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZoNBV2rvNHplIEJ8O0lFRtaZAFO34C91HmzsnvpgduyGYhFUB4PdCUc8aVT7RmY4NbGRl0 X-Received: by 2002:a17:902:b688:: with SMTP id c8-v6mr1121722pls.114.1536743757371; Wed, 12 Sep 2018 02:15:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536743757; cv=none; d=google.com; s=arc-20160816; b=xTTBqkB8d2rlCsgPNkve1tHF2x5SL42n4iTrALrHR51HgIaQlFxzEYt8W2kblW2jE4 fLTBX294YNJT6nnwylxytcfNvIFfpQ10V+9bO9eOa727ajVST3Cim3tM9LPCTjxl9mrs q4phiuYnzVBRqrw+kAJP3PVhfwyfVpCSOB9yQuJVAvPxfPPLtcX54wJAqPvcw2uPVWuc EL5wqrBBhR/XROx4zc6kbRVlcGYkE+m3gUkIUZs8p+Juf13cmHn5bKCTJJFZxWE/ydR7 6WWV1/TwAc4KrcKPXuCSs6jjREdn6xYZSEHUcXyJFTFUVV62a0hemXV/3uerJrjR/6HB m2WQ== 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; bh=OG3itvuW0UapMYXxL4gRewiOCBEZtuNS9v/cCqXD++o=; b=TlDMwussQmKuJbjwpkxIUg5wyNek+9q8sHYQeCKoBhsYNu46VFSufHHFlJkcacEct9 cIpscJ3i4mGazDWY5FJM7MI+iLsXSKvr+RuPKCIbr2e/g3nS96zxnIdsH222tOfKyfOt zO5gQuk0lNd4fKTkCBvUMYPQ16W1CNE7Gycn7+xFNEOXJTtzVe/2o/I2AFpF7zH6Jlhg FfvDQDvDMzN2RgccMStiyuIekp/x73xGyPKuJ+z7fJqKE53FYu+ArjtZvz9wRxQrol/0 R2NFf9cdBLLHegQ07MBHPBVFDxTJ6eygQObotV0GgYIOENuI/6sUZJGhn00dt8notIpl E3mg== 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 f6-v6si551472pgb.228.2018.09.12.02.15.41; Wed, 12 Sep 2018 02:15:57 -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 S1728222AbeILORe (ORCPT + 99 others); Wed, 12 Sep 2018 10:17:34 -0400 Received: from foss.arm.com ([217.140.101.70]:55956 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727753AbeILORd (ORCPT ); Wed, 12 Sep 2018 10:17:33 -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 4B3421596; Wed, 12 Sep 2018 02:13:56 -0700 (PDT) Received: from queper01-lin.local (queper01-lin.emea.arm.com [10.4.13.27]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 337D33F703; Wed, 12 Sep 2018 02:13:52 -0700 (PDT) From: Quentin Perret To: peterz@infradead.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Cc: gregkh@linuxfoundation.org, mingo@redhat.com, dietmar.eggemann@arm.com, morten.rasmussen@arm.com, chris.redpath@arm.com, patrick.bellasi@arm.com, valentin.schneider@arm.com, vincent.guittot@linaro.org, thara.gopinath@linaro.org, viresh.kumar@linaro.org, tkjos@google.com, joel@joelfernandes.org, smuckle@google.com, adharmap@codeaurora.org, skannan@codeaurora.org, pkondeti@codeaurora.org, juri.lelli@redhat.com, edubezval@gmail.com, srinivas.pandruvada@linux.intel.com, currojerez@riseup.net, javi.merino@kernel.org, quentin.perret@arm.com Subject: [PATCH v7 08/14] sched/topology: Disable EAS on inappropriate platforms Date: Wed, 12 Sep 2018 10:13:03 +0100 Message-Id: <20180912091309.7551-9-quentin.perret@arm.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180912091309.7551-1-quentin.perret@arm.com> References: <20180912091309.7551-1-quentin.perret@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Energy Aware Scheduling (EAS) in its current form is most relevant on platforms with asymmetric CPU topologies (e.g. Arm big.LITTLE) since this is where there is a lot of potential for saving energy through scheduling. This is particularly true since the Energy Model only includes the active power costs of CPUs, hence not providing enough data to compare packing-vs-spreading strategies. As such, disable EAS on root domains where the SD_ASYM_CPUCAPACITY flag is not set. While at it, disable EAS on systems where the complexity of the Energy Model is too high since that could lead to unacceptable scheduling overhead. All in all, EAS can be used on a root domain if and only if: 1. the ENERGY_AWARE sched_feat is enabled; 2. the root domain has an asymmetric CPU capacity topology; 3. the complexity of the root domain's EM is low enough to keep scheduling overheads low. cc: Ingo Molnar cc: Peter Zijlstra Signed-off-by: Quentin Perret --- kernel/sched/topology.c | 50 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 49 insertions(+), 1 deletion(-) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 10e37ffea19a..0d18d69b719c 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -270,12 +270,45 @@ static void destroy_perf_domain_rcu(struct rcu_head *rp) free_pd(pd); } +/* + * EAS can be used on a root domain if it meets all the following conditions: + * 1. the ENERGY_AWARE sched_feat is enabled; + * 2. the SD_ASYM_CPUCAPACITY flag is set in the sched_domain hierarchy. + * 3. the EM complexity is low enough to keep scheduling overheads low; + * + * The complexity of the Energy Model is defined as: + * + * C = nr_pd * (nr_cpus + nr_cs) + * + * with parameters defined as: + * - nr_pd: the number of performance domains + * - nr_cpus: the number of CPUs + * - nr_cs: the sum of the number of capacity states of all performance + * domains (for example, on a system with 2 performance domains, + * with 10 capacity states each, nr_cs = 2 * 10 = 20). + * + * It is generally not a good idea to use such a model in the wake-up path on + * very complex platforms because of the associated scheduling overheads. The + * arbitrary constraint below prevents that. It makes EAS usable up to 16 CPUs + * with per-CPU DVFS and less than 8 capacity states each, for example. + */ +#define EM_MAX_COMPLEXITY 2048 + static void build_perf_domains(const struct cpumask *cpu_map) { + int i, nr_pd = 0, nr_cs = 0, nr_cpus = cpumask_weight(cpu_map); struct perf_domain *pd = NULL, *tmp; int cpu = cpumask_first(cpu_map); struct root_domain *rd = cpu_rq(cpu)->rd; - int i; + + /* EAS is enabled for asymmetric CPU capacity topologies. */ + if (!per_cpu(sd_asym_cpucapacity, cpu)) { + if (sched_debug()) { + pr_info("rd %*pbl: CPUs do not have asymmetric capacities\n", + cpumask_pr_args(cpu_map)); + } + goto free; + } for_each_cpu(i, cpu_map) { /* Skip already covered CPUs. */ @@ -288,6 +321,21 @@ static void build_perf_domains(const struct cpumask *cpu_map) goto free; tmp->next = pd; pd = tmp; + + /* + * Count performance domains and capacity states for the + * complexity check. + */ + nr_pd++; + nr_cs += em_pd_nr_cap_states(pd->obj); + } + + /* Bail out if the Energy Model complexity is too high. */ + if (nr_pd * (nr_cs + nr_cpus) > EM_MAX_COMPLEXITY) { + if (sched_debug()) + pr_info("rd %*pbl: EM complexity is too high\n ", + cpumask_pr_args(cpu_map)); + goto free; } perf_domain_debug(cpu_map, pd); -- 2.18.0