Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp280826pxk; Thu, 24 Sep 2020 05:43:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzJ6TgZ8YSlXa0y4X510O0eGOAedASYGXBMdHN5DDwODCCEfqYLjRDW/LNQuq1S1XDMXFXA X-Received: by 2002:a17:906:cc8d:: with SMTP id oq13mr823062ejb.280.1600951412007; Thu, 24 Sep 2020 05:43:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600951411; cv=none; d=google.com; s=arc-20160816; b=h35ibhYP4uCZP0T7q3u8/AHbgUyZEsJ24SRSMv6hVvr1xVpbQyCyukYX7bo8uW6+f8 D9bktJjVuHf82+EOC+7eG/nBsyFODqFR7QKfeauo7FUwq7Tewh2k05JjyZsHBbhZFBQJ /stbwnLxaV3rl3wbNTMH9M3USBMK12pYopWBykllBHe7dGgD3rRj3ZTrrOmSBQYjCiRz xq0yaZCDG32vefJ9msepahP8KcSflhhC//pOPEHaIgTWkkMRvO3elyAJDj0HjF9iezzX PxRWJaHBJFTpPFXuVae316+3fOhv/MDErHIAROmDRHL9lq1Xi+D4c41bQPXoHfve7Bqz vRUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from; bh=B2gbAgMZPzamGx2xBce55IAWhI6N4dElprtXzyPgIBg=; b=iIRHUqAR7OKIw7ue1qFtbflvM60hD9SADhHAcDDPMTOyuMPPUJtcDdC5NG9rvl8R2O MGTH1YPU/WQ2vjfS8ZNLcz/RnIdvy3LBBlFvV9OcAZFtaRK+2VWxJao9Qovy5lF1cDPK 00nT9MQC4oR/GeviMfht4RP7bxUkcftzyxkZ5xw6NrJM+c0nbznBO1OBEBjij29ZDVXL rS2NBpAacXgWCQP2B4T9O3jKg7BBHZVw7Ww9/TG3V0mDd6CysDPCIp4did49fCuD0XEp z+dKUHKQ5LhfjGNiO6UZP9WAT0L6NVh6Sz42flCULWnYqY9WIT2Eo8IGLGlofzaH4RA5 ZPzA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h1si1890815ejg.341.2020.09.24.05.43.07; Thu, 24 Sep 2020 05:43:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727819AbgIXMkS (ORCPT + 99 others); Thu, 24 Sep 2020 08:40:18 -0400 Received: from foss.arm.com ([217.140.110.172]:45062 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727570AbgIXMkR (ORCPT ); Thu, 24 Sep 2020 08:40:17 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8E63A1396; Thu, 24 Sep 2020 05:40:16 -0700 (PDT) Received: from e108754-lin.cambridge.arm.com (unknown [10.1.199.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id C778A3F73B; Thu, 24 Sep 2020 05:40:14 -0700 (PDT) From: Ionela Voinescu To: mingo@redhat.com, peterz@infradead.org, vincent.guittot@linaro.org, catalin.marinas@arm.com, will@kernel.org, rjw@rjwysocki.net, viresh.kumar@linaro.org Cc: dietmar.eggemann@arm.com, qperret@google.com, valentin.schneider@arm.com, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, ionela.voinescu@arm.com Subject: [PATCH 2/3] sched/topology: condition EAS enablement on FIE support Date: Thu, 24 Sep 2020 13:39:36 +0100 Message-Id: <20200924123937.20938-3-ionela.voinescu@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200924123937.20938-1-ionela.voinescu@arm.com> References: <20200924123937.20938-1-ionela.voinescu@arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In order to make accurate predictions across CPUs and for all performance states, Energy Aware Scheduling (EAS) needs frequency-invariant load tracking signals. EAS task placement aims to minimize energy consumption, and does so in part by limiting the search space to only CPUs with the highest spare capacity (CPU capacity - CPU utilization) in their performance domain. Those candidates are the placement choices that will keep frequency at its lowest possible and therefore save the most energy. But without frequency invariance, a CPU's utilization is relative to the CPU's current performance level, and not relative to its maximum performance level, which determines its capacity. As a result, it will fail to correctly indicate any potential spare capacity obtained by an increase in a CPU's performance level. Therefore, a non-invariant utilization signal would render the EAS task placement logic invalid. Now that we properly report support for the Frequency Invariance Engine (FIE) through arch_scale_freq_invariant() for arm and arm64 systems, we can assert it is the case when initializing EAS. Warn and bail out otherwise. Signed-off-by: Ionela Voinescu Suggested-by: Quentin Perret Cc: Ingo Molnar Cc: Peter Zijlstra --- kernel/sched/topology.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 4073f693e2b5..348d563c2210 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -328,6 +328,7 @@ static void sched_energy_set(bool has_eas) * 3. no SMT is detected. * 4. the EM complexity is low enough to keep scheduling overheads low; * 5. schedutil is driving the frequency of all CPUs of the rd; + * 6. frequency invariance support is present; * * The complexity of the Energy Model is defined as: * @@ -376,6 +377,12 @@ static bool build_perf_domains(const struct cpumask *cpu_map) goto free; } + if (!arch_scale_freq_invariant()) { + pr_warn("rd %*pbl: Disabling EAS: frequency-invariant load tracking not supported", + cpumask_pr_args(cpu_map)); + goto free; + } + for_each_cpu(i, cpu_map) { /* Skip already covered CPUs. */ if (find_pd(pd, i)) -- 2.17.1