Received: by 10.213.65.68 with SMTP id h4csp1004719imn; Thu, 22 Mar 2018 13:11:34 -0700 (PDT) X-Google-Smtp-Source: AG47ELtadnIyZw1SnnE/oAVRHf8k1oP99+6y9AteHzwEEnE4V+SjgGRWaWihSapndOrG/gMRJk/t X-Received: by 2002:a17:902:b946:: with SMTP id h6-v6mr20452804pls.35.1521749494447; Thu, 22 Mar 2018 13:11:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521749494; cv=none; d=google.com; s=arc-20160816; b=S5L1zoGWhMQo2GFe6xajmxhS9w6MAVNG9mK4anoU/0fZkqdF33FcmbEfz34mDcqIOa IavGdRGXAbqM19CR7xiE9rK05gM2hUVhTCWWv1+D2luq+2XRqcrL/Shb1CzItb4zNJ7i ucj07qYyCqOsHtVvsTBMCyOCNH5bkOXyGW+fXhV9Se+0QTlHqKpPcNoLfM2pElZXv7Bs 3lmLjJQ4KTfFe557YwAJ9hzSyr8RwqvuKAzIZjeBCCZY1BtoZkSSo9JHDF87+X6b0ZvG Dz43P6CdIJvArEtqSAKmGyVX4NWfAQBBtx3iZS32YbUajqKLnLcPJCquiVPOxLByMjkE NQfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=g9QSkMS50Tn9JXVs8T5RMOvPOaEWxtXO1mgEQUlaV3w=; b=qEDd6UoXGgBzwyv243MqUZceMTNJLWRz58yZlFzBTCojBr8bAgMPv5ytjb9/o1Rab9 xC7Yd2vdpGxa0UKnq6oYVANqPpGwRywfEFc0dt+WNI+rVybzUiJulqUrCIxx+oy9gYDv GC4qGXqEHAIcZdrObokIwXJhVHtq0uSkh8juickTf+id8wWPl8PxwwKxXz3v0Mkg7A9D vusNrzZHogJx8tMXqVDw94r3vkgvCwwlrhws7yuA74S8sdzHKjzjQABsoJGr+xIT6qdi 3JYTJx9NdR+qCfkKvpwZWcuHCm4fEnzM+UcancyUP6bbrEjUN16Yzvn35vBFFIXsnwHM foLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=DJAnvynr; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o5si4808298pgp.16.2018.03.22.13.11.19; Thu, 22 Mar 2018 13:11:34 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=DJAnvynr; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751902AbeCVUKZ (ORCPT + 99 others); Thu, 22 Mar 2018 16:10:25 -0400 Received: from mail-it0-f51.google.com ([209.85.214.51]:38011 "EHLO mail-it0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751812AbeCVUKY (ORCPT ); Thu, 22 Mar 2018 16:10:24 -0400 Received: by mail-it0-f51.google.com with SMTP id 19-v6so12702947itw.3 for ; Thu, 22 Mar 2018 13:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g9QSkMS50Tn9JXVs8T5RMOvPOaEWxtXO1mgEQUlaV3w=; b=DJAnvynrEGzRG0wLe2y8o4GiyQX+W8kjr9QfqMBIAQderjQfvfi5EHMhdmOk816Y9h O8O9IN9gxI1unh/C++lVRReEjuDpOwbVywiz1lihwbpgyqjS+IX/T7t82fYK3zMZScmg EtRjzNO+DKnogLfSFKo4vDmWRqg8f6ze6OCoFstJ6PcomhHOxMY3T7XWkUmhlGu7ZQQf BO6gXrZ+ph0zPkcW2lzYLWUPMCPoqQtMTVnJzu8M3802TwVo19nuvQL2BK736/KDmjmS zuYMdCju7Hfb8RhDL8HN6/pinJh0f7/i/xnVmQ07Cmz/zrustZ5B+qflfN6fcZrDaZE1 gw1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g9QSkMS50Tn9JXVs8T5RMOvPOaEWxtXO1mgEQUlaV3w=; b=gOf8hILHI19Cr/DCYrBNVbDq5l5ns8y7Mi7Moqw1Dwxrt2RldvNSjXmkf7Drp7zXCZ HXWMtoyqu/qOoKhRjqooQC/YZbSIJRXL7XmaLR1rF0svLp6zu9ACOk3RqlrvN0+NOtIc 7x7jYoqhu93Rq6TTZiCGpUxOAnHtCEV1IAEUq5Rp+QpWfx8rB8n+zoTsiu0hYCPYo2bY bhMfl6cxBLpSDp2FdOEVECyGhCRnPCqwHfcx+E+0/r381vOV9ldI6SqHu1KSHFqi4kPg s+dQL2Tt3YPXaoRu3081l70uLMlbcXFA9FALmI+C/i7GggvMzwYD+Lk1PQssBIjiuldU Mcfg== X-Gm-Message-State: AElRT7E1iKLbXGY6ZT5J2ubKeVRf0YM+yeQn0OSeAlZU0ie4Mc5CHr0k 0dbTIDrYDVJdcTyFxfGz2YFF3+Ln5qOmRwJlh2eCRg== X-Received: by 2002:a24:9184:: with SMTP id i126-v6mr10872921ite.41.1521749422892; Thu, 22 Mar 2018 13:10:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.11.158 with HTTP; Thu, 22 Mar 2018 13:10:22 -0700 (PDT) In-Reply-To: <20180321153518.GC13951@e110439-lin> References: <20180320094312.24081-1-dietmar.eggemann@arm.com> <20180320094312.24081-6-dietmar.eggemann@arm.com> <20180321153518.GC13951@e110439-lin> From: Joel Fernandes Date: Thu, 22 Mar 2018 13:10:22 -0700 Message-ID: Subject: Re: [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up To: Patrick Bellasi Cc: Dietmar Eggemann , LKML , Peter Zijlstra , Quentin Perret , Thara Gopinath , Linux PM , Morten Rasmussen , Chris Redpath , Valentin Schneider , "Rafael J . Wysocki" , Greg Kroah-Hartman , Vincent Guittot , Viresh Kumar , Todd Kjos Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 21, 2018 at 8:35 AM, Patrick Bellasi wrote: > [...] > >> @@ -6555,6 +6613,14 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_f >> break; >> } >> >> + /* >> + * Energy-aware task placement is performed on the highest >> + * non-overutilized domain spanning over cpu and prev_cpu. >> + */ >> + if (want_energy && !sd_overutilized(tmp) && >> + cpumask_test_cpu(prev_cpu, sched_domain_span(tmp))) >> + energy_sd = tmp; >> + > > Not entirely sure, but I was trying to understand if we can avoid to > modify the definition of want_affine (in the previous chunk) and move > this block before the previous "if (want_affine..." (in mainline but > not in this chunk), which will became an else, e.g. > > if (want_energy && !sd_overutilized(tmp) && > // ... > else if (want_energy && !sd_overutilized(tmp) && > // ... > > Isn't that the same? > > Maybe there is a code path I'm missing... but otherwise it seems a > more self contained modification of select_task_rq_fair... Just replying to this here Patrick instead of the other thread. I think this is the right place for the block from Quentin quoted above because we want to search for the highest domain that is !overutilized and look among those for the candidates. So from that perspective, we can't move the block to the beginning and it seems to be in the right place. My main concern on the other thread was different, I was talking about the cases where sd_flag & tmp->flags don't match. In that case, sd = NULL would trump EAS and I was wondering if that's the right thing to do... thanks, - Joel [...]