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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1BFF7C433EF for ; Thu, 10 Mar 2022 06:40:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:CC:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=rb5edeyBPBh+orJ7UyUE0y5jc7Hk4DjDMTuxYaOMn3M=; b=noUxADi14FM2BDQbPgJTg2OfD9 W3aBp+3XVuKiGcvBRv6ZGEHGUxNjk+lVcOsxVDumKWWWsKCTNMb9thafXDPt0VeqzkS7CZesN7duK 85qogFEOVsAsbzRr6sBGrOsyKY6GWyiKsDePvo9C5x7nr7k3ILpOe/PcLDUIi9y4zd0Z1PdU7aRA+ 6RLiYMSYRBGGLwrxWduDKps8C2vgba6DWDRo03AgxYXek8ZC8xuNOrMAM9jlhemlHja1LBoEfxta7 EBaDOEpGMAKUUG70K5we+qSw4FVu7q0f55K4JvCxtju9jLTfnzb8t6DeL4k3wRKqiQgGoJC5ssShj UCPz4C2Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nSCSJ-00Bc87-1d; Thu, 10 Mar 2022 06:39:23 +0000 Received: from szxga01-in.huawei.com ([45.249.212.187]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nSCSB-00Bc5d-7y for linux-arm-kernel@lists.infradead.org; Thu, 10 Mar 2022 06:39:17 +0000 Received: from canpemm500009.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4KDfWd57tkzdb2m; Thu, 10 Mar 2022 14:37:49 +0800 (CST) Received: from [10.67.102.169] (10.67.102.169) by canpemm500009.china.huawei.com (7.192.105.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 10 Mar 2022 14:39:12 +0800 CC: , Sudeep Holla , "Rafael J . Wysocki" , Thomas Gleixner , Ingo Molnar , Giovanni Gherdovich , Catalin Marinas , Will Deacon , Valentin Schneider , Dietmar Eggemann , Sean Kelley , Pierre Gondois , , , Subject: Re: [PATCH v3 2/3] arch_topology: obtain cpu capacity using information from CPPC To: Ionela Voinescu References: <20220302180913.13229-1-ionela.voinescu@arm.com> <20220302180913.13229-3-ionela.voinescu@arm.com> <4283eacf-6eab-b2f5-07f2-d19fad134277@huawei.com> From: Yicong Yang Message-ID: <477748c7-ae9e-712b-90ad-b04a6767a996@huawei.com> Date: Thu, 10 Mar 2022 14:39:12 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.67.102.169] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To canpemm500009.china.huawei.com (7.192.105.203) X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220309_223915_684530_5530C926 X-CRM114-Status: GOOD ( 31.90 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 On 2022/3/9 23:37, Ionela Voinescu wrote: > Hi Yicong, > > On Wednesday 09 Mar 2022 at 18:21:30 (+0800), Yicong Yang wrote: >> Hi Ionela, >> >> On 2022/3/3 2:09, Ionela Voinescu wrote: >>> Define topology_init_cpu_capacity_cppc() to use highest performance >>> values from _CPC objects to obtain and set maximum capacity information >>> for each CPU. acpi_cppc_processor_probe() is a good point at which to >>> trigger the initialization of CPU (u-arch) capacity values, as at this >>> point the highest performance values can be obtained from each CPU's >>> _CPC objects. Architectures can therefore use this functionality >>> through arch_init_invariance_cppc(). >>> >>> The performance scale used by CPPC is a unified scale for all CPUs in >>> the system. Therefore, by obtaining the raw highest performance values >>> from the _CPC objects, and normalizing them on the [0, 1024] capacity >>> scale, used by the task scheduler, we obtain the CPU capacity of each >>> CPU. >>> >> >> So we're going to use highest performance rather than nominal performance, >> and I checked the discussion in v2 [1]. Maybe we should also document this >> in sched-capacity.rst that where scheduler get the capacity from on ACPI >> based system? Currently we only have DT part but after this patch it's >> also supported on ACPI based system. >> > > It's a very good point. I'll send a separate patch for this with added > information in "3.1 CPU capacity" in sched-capacity.rst. I'll send this > separate and not with the rebase that Rafael requested to avoid > confusing things. > sure. it's up to you. thanks. >> Out of curiosity, since we have raw capacity now on ACPI system, seems we >> are able to scale the capacity with freq_factor now? looked into >> register_cpufreq_notifier(). >> > > The freq_factor is only used for DT systems where one provides > "capacity-dmips-mhz" in DT. This entry actually represents DMIPS/MHz. > > So the freq_factor, set to: > > per_cpu(freq_factor, cpu) = policy->cpuinfo.max_freq / 1000; > > is used to obtain the performance at the maximum frequency, basically > DMIPS = (Dhrystone) million instructions per second, by multiplying this > raw value from DT with the freq_factor. After this, all these value for > each CPU type are normalized on a scale [0, 1024], resulting in what we > call CPU capacity. > Thanks for the illustration. I can understand what DT does as it's defined clearly in [1]. The CPUs in the system may have different capacity-dmips-mhz as well as frequency so we first obtain the DMIPS/MHz and then scaled it with the max frequency. > For ACPI systems freq_factor will have the default value of 1 when we > call topology_normalize_cpu_scale(), as the performance value obtained > from _CPC is already representative for the highest frequency of the CPU > and not performance/Hz as we get from DT. Therefore, we are not and > should not use a freq_factor here. > > Hopefully I understood your question correctly. > Seems we have different meaning of raw capacity on DT based and ACPI based system. On DT based system it doesn't consider the max frequency of each CPU so we need to take the frequency into account later. But on ACPI based system the max perf has already take the max frequency into account and we don't need to consider the frequency differences among the CPUs. If so, the comment [2] is no more correct as we don't need to scale the capcity according to the frequnecy but not because that we cannot get the raw cpu capacity on ACPI based system. The CPUs on ACPI based system may also have different DMIPS and maximum frequency, the same with the DT based system. Is it possible to keep consistence with what DT does? As defined by the spec[3], the CPPC aims to "maintaining a performance definition that backs a continuous, abstract, unit-less performance scale" and "leaves the definition of the exact performance metric to the platform." So is it possible we can also interpret it as "capacity-dmips-mhz"? Then to scale the cpu with max frequency provided by cpufreq, for example cppc_cpufreq. I'm not sure I'm right and understand it correctly, please correct me if I'm wrong. For this series, the arm64 part works and based on 5.17-rc7 I tested this on qemu with modified DSDT: estuary:/$ cat /sys/devices/system/cpu/cpu*/acpi_cppc/highest_perf 10000 10000 10000 10000 5000 5000 5000 5000 estuary:/$ cat /sys/devices/system/cpu/cpu*/cpu_capacity 1024 1024 1024 1024 512 512 512 512 If needed Tested-by: Yicong Yang [1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/arm/cpu-capacity.txt#L43 [2] https://github.com/torvalds/linux/blob/3bf7edc84a9eb4007dd9a0cb8878a7e1d5ec6a3b/drivers/base/arch_topology.c#L390 [3] https://uefi.org/specs/ACPI/6.4/08_Processor_Configuration_and_Control/declaring-processors.html#collaborative-processor-performance-control Thanks. > Thanks, > Ionela. > >> [1] https://lore.kernel.org/lkml/Yh5OAsYVBWWko+CH@arm.com/ >> >> Thanks, >> Yicong > . > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel