Received: by 10.213.65.68 with SMTP id h4csp496887imn; Fri, 23 Mar 2018 09:02:26 -0700 (PDT) X-Google-Smtp-Source: AG47ELt6sG6i56wYkXqdOqXOppmpBOkvPV/iL7ZyTmkOzpM5oTqp9/U1Xt9hA7Tfov2C6tuQWP5T X-Received: by 2002:a17:902:d03:: with SMTP id 3-v6mr30283471plu.245.1521820945951; Fri, 23 Mar 2018 09:02:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521820945; cv=none; d=google.com; s=arc-20160816; b=oGKaDrRF3sMAskJpXiY8U8N6EVfXQYDQn8BShXZUDzZHJp/zLIdJLYbS0PbjlU9CFD nZ1soLu2qtcdTUkXLaTNS2vOzFUi4Ee8F13o9BkUDcSxJOIcNsMLWDxytAEJRSraPix1 ZyYjM4AwIWhP3OK7m0B5+GG9HB6hWepmMxeTRm8UfP6P9XBAaAYIvq7L/ZtFrjcd9AID fvMtDikzc2w1bsDqSucrEGSHyfQ1vNqB36WDKRjTgQoaEDAPCIjjPGNS9iD/WP6I3cxy 6Hm8mo0lJF3YrvbzgPv/d9TRIet6biiiTnV6CZFZtXbZEWq1xXfspGRqRqcbUyD6yTCV jsBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=HCccpEIg9wQtGcsSfvckXSpvZHp+VkDXuzraV+HadfQ=; b=IdyFCqP8XT9s7N+2gU9Ln5kZHMciwIb5oCyiiw956sFhe2zIsMZKJ9/vtpgiCym77U xszOraaF3179/voO/czQ/FjdOihmYPvCdVcf4SOMGEDQpJsWTTORadOzQLystUsPvhPg WRqJKmbNNtOFHofviT4g6D3qMiI4E0gVP5ZsgZes7WEOxucUoZWbw7irK5NvVjJ/i67n HBJ0zX8B0fHJSDWx0Fz8n2wnPYB+oKh+blCMm9QTfT04+S6gq0E5mW7KbYjEDO2vTDFV arN092ravko+9v30rCNI8WEGRFd6q/PZ4wLi4IeBKXw113PPgHvdaxml+9T9WJHVXMR1 aUbw== 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 v4si6890299pfb.284.2018.03.23.09.02.05; Fri, 23 Mar 2018 09:02:25 -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 S1752203AbeCWQBH (ORCPT + 99 others); Fri, 23 Mar 2018 12:01:07 -0400 Received: from foss.arm.com ([217.140.101.70]:52526 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752161AbeCWQBF (ORCPT ); Fri, 23 Mar 2018 12:01:05 -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 9B8AD1435; Fri, 23 Mar 2018 09:01:04 -0700 (PDT) Received: from e105550-lin.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2077D3F487; Fri, 23 Mar 2018 09:01:01 -0700 (PDT) Date: Fri, 23 Mar 2018 16:00:59 +0000 From: Morten Rasmussen To: Joel Fernandes Cc: Dietmar Eggemann , LKML , Peter Zijlstra , Quentin Perret , Thara Gopinath , Linux PM , Chris Redpath , Patrick Bellasi , Valentin Schneider , "Rafael J . Wysocki" , Greg Kroah-Hartman , Vincent Guittot , Viresh Kumar , Todd Kjos Subject: Re: [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up Message-ID: <20180323160059.GQ4589@e105550-lin.cambridge.arm.com> References: <20180320094312.24081-1-dietmar.eggemann@arm.com> <20180320094312.24081-6-dietmar.eggemann@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 22, 2018 at 09:27:43AM -0700, Joel Fernandes wrote: > Hi, > > On Tue, Mar 20, 2018 at 2:43 AM, Dietmar Eggemann > wrote: > > > > From: Quentin Perret > > > > In case an energy model is available, waking tasks are re-routed into a > > new energy-aware placement algorithm. The eligible CPUs to be used in the > > energy-aware wakeup path are restricted to the highest non-overutilized > > sched_domain containing prev_cpu and this_cpu. If no such domain is found, > > the tasks go through the usual wake-up path, hence energy-aware placement > > happens only in lightly utilized scenarios. > > > > The selection of the most energy-efficient CPU for a task is achieved by > > estimating the impact on system-level active energy resulting from the > > placement of the task on each candidate CPU. The best CPU energy-wise is > > then selected if it saves a large enough amount of energy with respect to > > prev_cpu. > > > > Although it has already shown significant benefits on some existing > > targets, this brute force approach clearly cannot scale to platforms with > > numerous CPUs. This patch is an attempt to do something useful as writing > > a fast heuristic that performs reasonably well on a broad spectrum of > > architectures isn't an easy task. As a consequence, the scope of usability > > of the energy-aware wake-up path is restricted to systems with the > > SD_ASYM_CPUCAPACITY flag set. These systems not only show the most > > promising opportunities for saving energy but also typically feature a > > limited number of logical CPUs. > > > > Cc: Ingo Molnar > > Cc: Peter Zijlstra > > Signed-off-by: Quentin Perret > > Signed-off-by: Dietmar Eggemann > > --- > > kernel/sched/fair.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++--- > > 1 file changed, 71 insertions(+), 3 deletions(-) > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 76bd46502486..65a1bead0773 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -6513,6 +6513,60 @@ static unsigned long compute_energy(struct task_struct *p, int dst_cpu) > > return energy; > > } > > > > +static bool task_fits(struct task_struct *p, int cpu) > > +{ > > + unsigned long next_util = cpu_util_next(cpu, p, cpu); > > + > > + return util_fits_capacity(next_util, capacity_orig_of(cpu)); > > +} > > + > > +static int find_energy_efficient_cpu(struct sched_domain *sd, > > + struct task_struct *p, int prev_cpu) > > +{ > > + unsigned long cur_energy, prev_energy, best_energy; > > + int cpu, best_cpu = prev_cpu; > > + > > + if (!task_util(p)) > > + return prev_cpu; > > + > > + /* Compute the energy impact of leaving the task on prev_cpu. */ > > + prev_energy = best_energy = compute_energy(p, prev_cpu); > > Is it possible that before the wakeup, the task's affinity is changed > so that p->cpus_allowed no longer contains prev_cpu ? In that case > prev_energy wouldn't matter since previous CPU is no longer an option? It is possible to wake-up with a disallowed prev_cpu. In fact select_idle_sibling() may happily return a disallowed cpu in that case. The mistake gets fixed in select_task_rq() which uses select_fallback_rq() to find an allowed cpu instead. Could we fix the issue in find_energy_efficient_cpu() by a simple test like below if (cpumask_test_cpu(prev_cpu, &p->cpus_allowed)) prev_energy = best_energy = compute_energy(p, prev_cpu); else prev_energy = best_energy = ULONG_MAX;