Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp593897ybz; Wed, 15 Apr 2020 14:45:56 -0700 (PDT) X-Google-Smtp-Source: APiQypIvk+sdLjtzU2CfSZU43rYZZEg6HgxrEgRMFLO90ZDLpx9eQYYdlsmUih+a98ggosjcw7Dz X-Received: by 2002:a17:906:4c98:: with SMTP id q24mr6849669eju.140.1586987156421; Wed, 15 Apr 2020 14:45:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586987156; cv=none; d=google.com; s=arc-20160816; b=VgekFGkFUuP5rA48qGTXC+fbOXkLDrKZe/BEBXAI745q3sjEsDBCYyioabt6uf6RLV E+KnPdN0v4P1DS6svzNQEzFrs5Ai/zFJi7SWzabQ/J27CbEUcJLIyAemCMiX1GbjrQ3U 7u/QbHC/a+yynO9esRRouP30Ej1qq2aWG5HanJNjBR/E5To/MSqjU82rFYQb6Srp6s8+ hkT1Ykq6oWdTr72SvDPYEIDLs7Zdlx+it6q9P/QdT5k6T1GncIKzTvRjWthnJk6t92Nx 2EVr0JLqYSKTaA8QYnvKXF00wA4ZCTjv4PqjghDnXH2mzIDxvPAKYaWlpTdx+C4aD7EG 7/Ww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=N+n9AfdgCHZHPLEZwn0rArerGah9Sin8ZS1sOBMYBSk=; b=HqSiwTP1SZbrmdErREtzbnr0HVC+XIIHUA+u9wX/ZJ5r5yf2Ce0qkTCUSqNDe5R3tQ gq8RQg6FKSF/GnViS40PgjUv3xYMgRUWa7r0gwbmz8P6jTdLwi5fE5busS0giP1qRApa qaJLpl0CrdPXOBsJtGUBWiBAbaDmJ4nKi3a3e8CqFHunj9Elt01y6iYHSuV4Jourgjsc ON2D8R0dzI/4KhnXS7G9FXM4iss9I0yzKHDjQxYcuj59wtFTm4zhtfyZ2A91OgGoGtZv cMiFXMoJcGGAKF6i+D9Vy843ZMScAV4d2cnHB4rsJID1XXu2n/ds/1hoFH/bpQQmJ1qd 6rCQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a24si4553844eds.168.2020.04.15.14.45.32; Wed, 15 Apr 2020 14:45:56 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2440371AbgDNP15 (ORCPT + 99 others); Tue, 14 Apr 2020 11:27:57 -0400 Received: from foss.arm.com ([217.140.110.172]:58326 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2439713AbgDNP1b (ORCPT ); Tue, 14 Apr 2020 11:27:31 -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 C8D8630E; Tue, 14 Apr 2020 08:27:30 -0700 (PDT) Received: from [192.168.1.19] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B49353F73D; Tue, 14 Apr 2020 08:27:27 -0700 (PDT) Subject: Re: [PATCH 1/4] sched/topology: Store root domain CPU capacity sum To: Quentin Perret , Vincent Guittot Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Steven Rostedt , Luca Abeni , Daniel Bristot de Oliveira , Wei Wang , Alessio Balsini , Pavan Kondeti , Patrick Bellasi , Morten Rasmussen , Valentin Schneider , Qais Yousef , linux-kernel References: <20200408095012.3819-1-dietmar.eggemann@arm.com> <20200408095012.3819-2-dietmar.eggemann@arm.com> <42cc3878-4c57-96ba-3ebd-1b4d4ef87fae@arm.com> <20200414124503.GA236568@google.com> From: Dietmar Eggemann Message-ID: <7adf893b-769d-ffa4-71da-d9a93646a88c@arm.com> Date: Tue, 14 Apr 2020 17:27:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200414124503.GA236568@google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14.04.20 14:45, Quentin Perret wrote: > On Wednesday 08 Apr 2020 at 19:03:57 (+0200), Vincent Guittot wrote: >> Or we can do the opposite and only use capacity_orig_of()/rq->cpu_capacity_orig. >> >> Is there a case where the max cpu capacity changes over time ? So I >> would prefer to use cpu_capacity_orig which is a field of scheduler >> instead of always calling an external arch specific function > > Note however that using arch_scale_cpu_capacity() would be more > efficient, especially on non-arm/arm64 systems where it is a > compile-time constant. or essentially all ARCHs not defining it. > > It's probably a matter of personal taste, but I find rq->cpu_capacity_orig > superfluous. It wastes space without actually giving you anything no? > Anybody remembers why it was introduced in the first place? v3.18 arm providing arch_scale_cpu_capacity() v4.1 introduction of rq->cpu_capacity_orig v4.10 arm64 providing arch_scale_cpu_capacity() ... So it's down to the question of 'minimizing the scheduler calls to an external arch function' vs 'efficiency'.