From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E6F7C4361B for ; Mon, 14 Dec 2020 16:16:12 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 40DDA2255F for ; Mon, 14 Dec 2020 16:16:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 40DDA2255F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=8q4JEjo2Oy8HL17FbEETvGo+19TYAJvBLlHIVNyEkRM=; b=adZA0VfPYmAEWEZ18iOX0SmcK TM8q0Nk1bUa29oK/p2i+zIQa2LmMW9aOaUc8l/Qg2Oy/VfoTVt0RUBFiE3Ft3XSLTRa+TRZpeghj8 WIUBbkigs2qxjxI+GftPAV90TpPT8is/iE6zm3nmktagHsms652JoxDIyinmh9falkFrezJ3v4W92 g7GgTDnuUIiHYzwai2Vd+tuA46axHXGR6wSnFWTBr75hkFQGWqadePajrVrTko4GXcA1KdB2paca0 fzfgPvCSqwlHyzgUd0w7vOEoDi5FIJyCA0FwCoQ1QtLzQHHQlzjBM9IcnJqRtGSq1Dgdjiv44s4Y2 ci0H/Hfqw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1koqUy-0006tr-4A; Mon, 14 Dec 2020 16:14:56 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1koqUv-0006tU-JI for linux-arm-kernel@lists.infradead.org; Mon, 14 Dec 2020 16:14:54 +0000 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 A862630E; Mon, 14 Dec 2020 08:14:52 -0800 (PST) Received: from localhost (unknown [10.1.198.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4097C3F66B; Mon, 14 Dec 2020 08:14:52 -0800 (PST) Date: Mon, 14 Dec 2020 16:14:50 +0000 From: Ionela Voinescu To: Viresh Kumar Subject: Re: [PATCH] arm64: topology: Cleanup init_amu_fie() a bit Message-ID: <20201214161450.GA20030@arm.com> References: <5594c7d6756a47b473ceb6f48cc217458db32ab0.1607584435.git.viresh.kumar@linaro.org> <20201210103815.GA3313@arm.com> <20201211110555.ht3stotrpbkkdxju@vireshk-i7> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201211110555.ht3stotrpbkkdxju@vireshk-i7> User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201214_111453_775309_E660FEF8 X-CRM114-Status: GOOD ( 21.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Vincent Guittot Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, Sorry, I missed this. On Friday 11 Dec 2020 at 16:35:55 (+0530), Viresh Kumar wrote: > On 10-12-20, 10:38, Ionela Voinescu wrote: > > Basically, that's functions purpose is only to make sure that invariance > > at the level of the policy is consistent: either all CPUs in a policy > > support counters and counters will be used for the scale factor, or > > either none or only some support counters and therefore the default > > cpufreq implementation will be used (arch_set_freq_scale()) for all CPUs > > in a policy. > > Why is it important to have this thing at policy level ? If we are > okay with only one policy having AMUs and not the other one, then what > about only some CPUs of both the policies having it. Does it break > anything ? > First of all, in order for a single CPU in a policy to use AMUs for FIE, when the others do not support AMUs, we'd have to modify arch_set_freq_scale() which otherwise would uniformly set its own computed scale factor for all related CPUs. Beyond this, it's very likely that CPUs in the same policy have the same uarch and therefore either all or none in the policy would support AMUs. The check here is just to make sure of that and then ensure that arch_set_freq_scale() and arch_scale_freq_tick() do not clash with each other. Beyond this, it's difficult to say how important it is to have the same scale for all CPUs in a policy. AMUs would give you a scale based on an average frequency between ticks, and more importantly it would be based on the actual core frequency, not on what software requested. Cpufreq would give you the scale obtained using the frequency that the OS requested. Therefore, the two scale values could end up being quite different, and therefore can result in quite different utilization values for CPUs doing the same work. An alternative would be to apply the AMU computed scale to all CPUs although not all CPUs in a policy might support AMUs. But given that this scenario is unlikely, the added hassle in arch_scale_freq_tick() which would involve getting information on related CPUs from policies was not worth it, in my opionion. Thanks, Ionela. > -- > viresh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel