Received: by 10.213.65.68 with SMTP id h4csp970506imn; Fri, 23 Mar 2018 23:08:13 -0700 (PDT) X-Google-Smtp-Source: AG47ELta2Lwwc5qgaJF2F3yiDRyV/6Ng+cDOvBSA3rI6ZW2cCQMsTzTgiSy7CqTCieun71z/fNRs X-Received: by 2002:a17:902:a582:: with SMTP id az2-v6mr17383730plb.37.1521871693370; Fri, 23 Mar 2018 23:08:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521871693; cv=none; d=google.com; s=arc-20160816; b=xSRoKHzdKumDt8Rw8ofYIceIzUiGtZcs/EdtqcnKXhblzN2NHP4j76V4DMC84WsSHy aLGchTOvez+JPyM9aV7zC8FwmFgzQLFpjRriYk9fGPHwz6mBaG/KeycFa2P92SoLm0AC QWUpo6fu7FnnCcVW5K5Edv++Y2eNPl5WimX7GE/F3FVkS1ezIRA3IrIDC2tOL03MQCw4 xy3RqgyAjFLU0zllIiAR5Qkjaa5QgCFKKp8bZEMnPFiCpvTxz7s6zLabhBm15XrJIgvU 7/zqixR4EygbH+EUgfVgNjqUyw2r/A+HhdOCrUnDZEOkdvwMgPohldkjtDbfNHjs6d8l PeGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:from:cc:to:subject :content-transfer-encoding:mime-version:references:in-reply-to :user-agent:date:dkim-signature:arc-authentication-results; bh=hjgC5i56QoY9GB3eRH51ewoWgNLwLWVMlt9r5vzXPa4=; b=ZVSITTBhhmicOc9NYuGMq0OLsa8P7F6dWQRxgtltD2SOaC+L1iaVGaFSC6U7y1x3p4 NGXedKIwUoQicxo+L1aO/No7Xj2DnVfptkuU6DB57ZkQVLxcuKfmWmDU8E6JrEvsi82W eRqjE84XnISpPiZay5Ba0iQsioFqHWndPkX7AQcaBd/7kZ1pqzRbhc3rbA6DQAIOm9jX NgFSto9uj33zNT8g9i0psfIpSBmmq3+HW7gJaN0L9WkHchgsW8bmsiz/74y6DNg1JSvn U3vPdl43DhSHJvtrwNT2aNExVtnxN8wrSiG49dPXZpf1MTh3sD8zbw5DstjQt0YW0DtF 8V1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=moI4qKez; 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=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m11si5836004pgd.683.2018.03.23.23.07.46; Fri, 23 Mar 2018 23:08:13 -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=fail header.i=@gmail.com header.s=20161025 header.b=moI4qKez; 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=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750933AbeCXGGV (ORCPT + 99 others); Sat, 24 Mar 2018 02:06:21 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:39154 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750734AbeCXGGT (ORCPT ); Sat, 24 Mar 2018 02:06:19 -0400 Received: by mail-pf0-f193.google.com with SMTP id u5so5552302pfh.6; Fri, 23 Mar 2018 23:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=hjgC5i56QoY9GB3eRH51ewoWgNLwLWVMlt9r5vzXPa4=; b=moI4qKezAc5ORzLRMgVpP7t5yiHYjsiI0nmAcIfpqGpayfeNgkSso3EA/wyYOl23LC EiHUvODmwMJ1ShHq2hT8gfnaON2UkanzS67UVKXegr/IF7tWVyPw4cyVp4Hij3fx2/8I mwiVXsfXXaR3SS4HexbHiHsSVZS1uYWR9G7gi8qVxQz1O4emEdvOly+OaSaOcdsRh635 UTLo0JlbkMtxLUNAEVgUZP1cUBOEgFKBGvR26ER6CDELX6DOYV/ah6xJ76XjrQZAwz5t 6J7u1fnv04oPJGcjW6tiQRFsuK6s343sptCF3cERvs70p4E00AAYjlAvB2aN20BO9ziW hNxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:cc:from :message-id; bh=hjgC5i56QoY9GB3eRH51ewoWgNLwLWVMlt9r5vzXPa4=; b=tPg6AHQAW4EnozdSzW38GqeXudayvnb0g9LqGHHunaqTd2yL7pN7iKA0Eg9LYxTOUi g5/o/U15Mkz7BwAGihgExAdKTVrSVQ9KiVS9IBMGJ9QjDPJmMTMaiihwDRw9NKaFe/mp QMNy1mzAW9H67snGR+D7/JmD07hQ1cjHYaqVCpAehv0qPft0gutjd6d2e6UqHw/q/QRK izKl/ZAc0DRUXiFMQ8tO674sH0BUng9G9I97G+/KqIBLx3nNNQ+zpsISM1LIZgnVoDFA LKByd9QAoicgEm8dqXF7WstQkhE5rwxssHgPE+iO+Cxu1nHL4OxHk7N55Qm8NIG277eK s4nw== X-Gm-Message-State: AElRT7Hi+jPQWNo+Q+C649zmw5t8MS+AjAid+549R9jCamj3HPlFVWA6 Kowd/kSbaQzodvdtyV/YX9g= X-Received: by 10.98.19.132 with SMTP id 4mr17795112pft.87.1521871579042; Fri, 23 Mar 2018 23:06:19 -0700 (PDT) Received: from [192.168.0.114] ([24.6.205.35]) by smtp.gmail.com with ESMTPSA id z21sm16479371pge.42.2018.03.23.23.06.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Mar 2018 23:06:17 -0700 (PDT) Date: Fri, 23 Mar 2018 23:06:11 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <20180324013421.GB1317@queper01-VirtualBox> References: <20180320094312.24081-1-dietmar.eggemann@arm.com> <20180320094312.24081-6-dietmar.eggemann@arm.com> <20180321153518.GC13951@e110439-lin> <20180323154745.GP4589@e105550-lin.cambridge.arm.com> <20180324013421.GB1317@queper01-VirtualBox> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up To: Quentin Perret , Joel Fernandes CC: Morten Rasmussen , Patrick Bellasi , Dietmar Eggemann , LKML , Peter Zijlstra , Thara Gopinath , Linux PM , Chris Redpath , Valentin Schneider , "Rafael J . Wysocki" , Greg Kroah-Hartman , Vincent Guittot , Viresh Kumar , Todd Kjos From: Joel Fernandes Message-ID: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On March 23, 2018 6:34:22 PM PDT, Quentin Perret wrote: >On Friday 23 Mar 2018 at 18:13:56 (-0700), Joel Fernandes wrote: >> Hi Morten, >>=20 >> On Fri, Mar 23, 2018 at 8:47 AM, Morten Rasmussen >> wrote: >> > On Thu, Mar 22, 2018 at 01:10:22PM -0700, Joel Fernandes wrote: > >[=2E=2E=2E] > >> > You mean if SD_BALANCE_WAKE isn't set on sched_domains? >>=20 >> Yes=2E >>=20 >> > The current code seems to rely on that flag to be set to work >correctly=2E >> > Otherwise, the loop might bail out on !want_affine and we end up >doing >> > the find_energy_efficient_cpu() on the lowest level sched_domain >even if >> > there is higher level one which isn't over-utilized=2E >> > >> > However, SD_BALANCE_WAKE should be set if SD_ASYM_CPUCAPACITY is >set so >> > sd =3D=3D NULL shouldn't be possible? This only holds as long as we >only >> > want EAS for asymmetric systems=2E >>=20 >> Yes, I see you had topology code that set SD_BALANCE_WAKE for ASYM=2E >It >> makes sense to me then, thanks for the clarification=2E >>=20 >> Still I feel it is a bit tedious/confusing when reading code to draw >> the conclusion about why sd is checked first before doing >> find_energy_efficient_cpu (and that sd will !=3D NULL for ASYM >systems)=2E >> If energy_sd is set, then we can just proceed with EAS without >> checking that sd !=3D NULL=2E This function in mainline is already pret= ty >> confusing as it is :-( > >Right I see your point=2E The code is correct as is, but I agree that >having >a code structured as > > if (energy_sd) { > new_cpu =3D find_energy_efficient_cpu(energy_sd, p, prev_cpu); > } else if (!sd) { > =2E=2E=2E > >might be easier to understand and functionally equivalent=2E What do you >think ? Yeah definitely=2E Go for it=2E - Joel --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E