Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp1241638pxv; Fri, 25 Jun 2021 08:27:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw6sPXVwVa4xXMUCXGbAlS+HOX9DgNBbFA1p7p/hY33XFfgPVs5PzJwrrMgzBPAhZxazhKM X-Received: by 2002:a05:6e02:8ee:: with SMTP id n14mr7647767ilt.205.1624634844360; Fri, 25 Jun 2021 08:27:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624634844; cv=none; d=google.com; s=arc-20160816; b=rpD6R2fxZGWPca4gxOr4+DMDwqajKX0OWmPyvjBL/Q5bfshYbzVDVoCckSOugpaQHY J/z44fXIdKhc0/ky7ZKzlXBidEiUhuyUJugYClHhLNf74/BwQrkq621+nNhOMc9CP+g+ p/W1Cm7fz08BfqyYJRhciIiNGseJmsXCrfnSEFXSLAE1vPs6L8Z5TlTqlSbE1anaZPki xDEa2FDFTEgc7lIoMxYg3Uy6nmAfaQcrEvamkvrj5H/HZ1ZGUaYPD9TvE6Yd0yLV/yfp IulRr8rEs4XuaVlo9NCAatoXie8JA8q43ZoVz31J1C8r0Bdicfk7OofJPJ0nzJdY/Ild W1Ew== 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=4OCpKezEQBPt3Htv2O4yOVF+UEA1vGVNx8mhrZHdCW0=; b=NPxR8s0pXy/JZ4KWspEFV3TXsAjBJHZBPARjPcfdyiHpjrbJQwN9oslDv6AXyvbIvE nwI1d2i3AF9l0b32P7ABAcarXjC6jIm1DfYdyagIBSkbJhBY0bOj2kTh46RwAy/GWh8Y y86zGpdBxmFBB1kJHsRgWnIF+hMMdwV2+oSktyWbjNO/rgSoq7xsu6QZ8jPpVHUSRTyG AEcCB3K56TRTP7ijTJOEFgNxFCjdjQYM9vgJHBGT6kuhOyF9Mqd0Q4dCqWrxDfSwxlRm /8u/mr5T1ZSMpPOhVM/j+6BnnmbrUUmVpRbO3kms059oivax15Ky9LB3nN0fN+deCj01 cBkw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p14si7441809ils.62.2021.06.25.08.27.12; Fri, 25 Jun 2021 08:27:24 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229826AbhFYP3E (ORCPT + 99 others); Fri, 25 Jun 2021 11:29:04 -0400 Received: from foss.arm.com ([217.140.110.172]:58636 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229445AbhFYP3D (ORCPT ); Fri, 25 Jun 2021 11:29:03 -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 B3C6F12FC; Fri, 25 Jun 2021 08:26:42 -0700 (PDT) Received: from e123648.arm.com (unknown [10.57.7.232]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 90EF23F694; Fri, 25 Jun 2021 08:26:39 -0700 (PDT) From: Lukasz Luba To: linux-kernel@vger.kernel.org Cc: Chris.Redpath@arm.com, lukasz.luba@arm.com, dietmar.eggemann@arm.com, morten.rasmussen@arm.com, qperret@google.com, linux-pm@vger.kernel.org, peterz@infradead.org, rjw@rjwysocki.net, viresh.kumar@linaro.org, vincent.guittot@linaro.org, mingo@redhat.com, juri.lelli@redhat.com, rostedt@goodmis.org, segall@google.com, mgorman@suse.de, bristot@redhat.com, CCj.Yeh@mediatek.com Subject: [PATCH 1/3] sched/fair: Prepare variables for increased precision of EAS estimated energy Date: Fri, 25 Jun 2021 16:26:01 +0100 Message-Id: <20210625152603.25960-2-lukasz.luba@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20210625152603.25960-1-lukasz.luba@arm.com> References: <20210625152603.25960-1-lukasz.luba@arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The Energy Aware Scheduler (EAS) tries to find best CPU for a waking up task. It probes many possibilities and compares the estimated energy values for different scenarios. For calculating those energy values it relies on Energy Model (EM) data and em_cpu_energy(). The precision which is used in EM data is in milli-Watts (or abstract scale), which sometimes is not sufficient. In some cases it might happen that two CPUs from different Performance Domains (PDs) get the same calculated value for a given task placement, but in more precised scale, they might differ. This rounding error has to be addressed. This patch prepares EAS code for better precision in the coming EM improvements. Signed-off-by: Lukasz Luba --- kernel/sched/fair.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 7b8990fd4896..b517c9e79768 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -6582,7 +6582,7 @@ static unsigned long cpu_util_next(int cpu, struct task_struct *p, int dst_cpu) * to compute what would be the energy if we decided to actually migrate that * task. */ -static long +static u64 compute_energy(struct task_struct *p, int dst_cpu, struct perf_domain *pd) { struct cpumask *pd_mask = perf_domain_span(pd); @@ -6689,12 +6689,13 @@ compute_energy(struct task_struct *p, int dst_cpu, struct perf_domain *pd) */ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu) { - unsigned long prev_delta = ULONG_MAX, best_delta = ULONG_MAX; struct root_domain *rd = cpu_rq(smp_processor_id())->rd; + u64 prev_delta = ULLONG_MAX, best_delta = ULLONG_MAX; int cpu, best_energy_cpu = prev_cpu, target = -1; - unsigned long cpu_cap, util, base_energy = 0; + unsigned long cpu_cap, util; struct sched_domain *sd; struct perf_domain *pd; + u64 base_energy = 0; rcu_read_lock(); pd = rcu_dereference(rd->pd); @@ -6718,9 +6719,9 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu) goto unlock; for (; pd; pd = pd->next) { - unsigned long cur_delta, spare_cap, max_spare_cap = 0; + unsigned long spare_cap, max_spare_cap = 0; bool compute_prev_delta = false; - unsigned long base_energy_pd; + u64 base_energy_pd, cur_delta; int max_spare_cap_cpu = -1; for_each_cpu_and(cpu, perf_domain_span(pd), sched_domain_span(sd)) { @@ -6790,7 +6791,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu) * Pick the best CPU if prev_cpu cannot be used, or if it saves at * least 6% of the energy used by prev_cpu. */ - if ((prev_delta == ULONG_MAX) || + if ((prev_delta == ULLONG_MAX) || (prev_delta - best_delta) > ((prev_delta + base_energy) >> 4)) target = best_energy_cpu; -- 2.17.1