Received: by 10.213.65.68 with SMTP id h4csp843446imn; Fri, 23 Mar 2018 18:35:42 -0700 (PDT) X-Google-Smtp-Source: AG47ELtbwcjaarUN7XdQwIoCGOGiE8N7stvUDft+wMdFhvnDXa7aSey214bfT+aPXASMlDQAlIVW X-Received: by 2002:a17:902:8f8c:: with SMTP id z12-v6mr22330711plo.400.1521855342403; Fri, 23 Mar 2018 18:35:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521855342; cv=none; d=google.com; s=arc-20160816; b=lOBd7RCC/ul0SnR/XhAWQTZKv5qO1Xx8SSa2Gx4qJltJRC/9jybolHtdky1YyobHXN 0BZ5XgeFITwjWpiA9bpNy3MDrue8hQQu126fISJp1+ZAE3EGVr6ajt6LW+e6tJ4oU0p9 6b/ONmbt3n5Wg3riPxrYCwaGhod8r6PpDCtOkMwsHS+kDepLnRu5xN+gLLrm4OG4PcAX Crw332rhq+0lOcHTS73VaR2XOLuOq59ajNHiYmFpUHWi84KsELvkniIL9+mt1JpA57vD tnX8fLipWk44M4XRtdWrxLzFnDHOCv96SOYqv/hmrWMd2tuMoS49VQIX4pBxrwLgoDlV Ik4A== 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=mQjfRKPgRqzaOhCzK8IfJ4l2wtXOVdMbpyVyvnmqAhs=; b=mXntnOrUQ/f+fJ2vvTYfhFs+lZfG8fIaJQOLtn4WhFwy0peceXoH5HKXRA/dyu6Gwz b+u5TeTjt6Wii0/zQjlUSQHMOTWvtMTAsfU048CcX71ynQYvRs9+ZgcBGJL3QzPucJHD R6zNV+Huy2ftHNKlhv9CxMRrB1lD3lQnansomIeledBV26SafXSELFALVZ8eQ36APwIj Xz+J8NqaiPetzkAU7MJsHIIoSn1DA61XOWtAPh5Qf8wSPJFyZ7c+o+g+7lGDap+ciUb4 6alF6fYcWMg8fwai/cWYqz6eboykTeH9whYsPcdypB6pZEPTAINBRpzFjwQ4UPdxK5bT VeMg== 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 f9si6792452pgn.493.2018.03.23.18.35.27; Fri, 23 Mar 2018 18:35:42 -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 S1752060AbeCXBea (ORCPT + 99 others); Fri, 23 Mar 2018 21:34:30 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:57048 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751837AbeCXBe2 (ORCPT ); Fri, 23 Mar 2018 21:34:28 -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 6D1EE80D; Fri, 23 Mar 2018 18:34:28 -0700 (PDT) Received: from queper01-VirtualBox (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7C7773F487; Fri, 23 Mar 2018 18:34:24 -0700 (PDT) Date: Sat, 24 Mar 2018 01:34:22 +0000 From: Quentin Perret To: 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 Subject: Re: [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 23 Mar 2018 at 18:13:56 (-0700), Joel Fernandes wrote: > Hi Morten, > > 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: [...] > > You mean if SD_BALANCE_WAKE isn't set on sched_domains? > > Yes. > > > The current code seems to rely on that flag to be set to work correctly. > > 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. > > > > However, SD_BALANCE_WAKE should be set if SD_ASYM_CPUCAPACITY is set so > > sd == NULL shouldn't be possible? This only holds as long as we only > > want EAS for asymmetric systems. > > Yes, I see you had topology code that set SD_BALANCE_WAKE for ASYM. It > makes sense to me then, thanks for the clarification. > > 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 != NULL for ASYM systems). > If energy_sd is set, then we can just proceed with EAS without > checking that sd != NULL. This function in mainline is already pretty > confusing as it is :-( Right I see your point. The code is correct as is, but I agree that having a code structured as if (energy_sd) { new_cpu = find_energy_efficient_cpu(energy_sd, p, prev_cpu); } else if (!sd) { ... might be easier to understand and functionally equivalent. What do you think ? Thanks, Quentin