Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp159744pxp; Wed, 16 Mar 2022 02:55:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+qxmkMxmtp+S5tSpwHsr7juhFw/vYmd5RQyxhGLrO3IO1T1Iaermv1C9SgD8HbgWjvz8X X-Received: by 2002:a17:903:1108:b0:151:9c42:7d1 with SMTP id n8-20020a170903110800b001519c4207d1mr32898853plh.54.1647424521227; Wed, 16 Mar 2022 02:55:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647424521; cv=none; d=google.com; s=arc-20160816; b=CCE1DmHxQIwDwB5w8VBp3UwPqISHziImu1rRX7en25I+5NiVsmYe6nFV30dB18FMsy KTIpkGavTVOV8USuDbfS84SiXZruwpM8M5touLYW7iWB8YoYjVgQP+zpOXtBdO25F7Rs +Uylj85DX7WFjoDWZpc4aVXFsfS8TnnCD6wqYXfWImt9YXkX5rix00tyb95Xce1PE5rS umeTvAlb60Bbl/LnZxhi9++wVdzWhYzP43U/wTTmmP1wQtYsZ/D/wCXHsTJC/FkRL4Qr lDDYoJXA4a/gNjuPw8fkS/dI+WP0K6EY6QD76ChJWajlOOx+hF9m4noWoqRi9H1gHzRs NSCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=sFlYEAQckeRXon3Gb7dVboi70GiJgP07IOxKz1DUs5s=; b=X7cS9XnlDQVF1QEaJzshd/NXkjFgwD521IPv0PmcGU7g8Yx+yEsslWaEvtQQTAQeCW G9I3aNY/pTu4xBrMKc6EfD6+2q175fKo+sZEWP7tsKcMriejmvI7aUjHZODAw+rf+3QN Fwpljs+ebBrCoZdDlYCA4vAnf5EltgEbmjfYC0HRSqfRlQFtcP/lR5JBcwUUYGS8Msv4 aXuVSnUxWrg1dP9U5F9WxoCoRA1HZ25PJZ3gX7645bZPDqTsuUvQTZ17wc5nUjRdjk/B 1bQGm0v7QEYktUuJFI6yb0zQdGwolqTBt4/xwcuN1bdm6jGYTu7cX4nT1VxEYdo94wNS /vlA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=pMOwCnvI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bo20-20020a17090b091400b001bf71c29144si4281335pjb.55.2022.03.16.02.55.09; Wed, 16 Mar 2022 02:55:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=pMOwCnvI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233687AbiCMF4v (ORCPT + 99 others); Sun, 13 Mar 2022 00:56:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233677AbiCMF4s (ORCPT ); Sun, 13 Mar 2022 00:56:48 -0500 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D12705C84A for ; Sat, 12 Mar 2022 21:55:40 -0800 (PST) Received: by mail-pj1-x1029.google.com with SMTP id d10-20020a17090a7bca00b001c5ed9a196bso706156pjl.1 for ; Sat, 12 Mar 2022 21:55:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=sFlYEAQckeRXon3Gb7dVboi70GiJgP07IOxKz1DUs5s=; b=pMOwCnvI12AKaRkWveBPimdXWZxUhOX8XXJtN07f7lfryegGQwbpP3kRdQIqw3UkEZ qdo+Nydo02HpHPQXtpV45dD+K0eSWI5WcSY37yGEfZBKpWyzkgw+OQImfr0XtqA/Krn+ CTS65jz+XcKKtXJqn/q+VnfPnuAGRYc4gXzSLVwXHWE4nBz9n/A0amBHeRo3f0QgJazX k1OOQBD0UWQsUBbyyBkiz8z5Y3k/xD+8MIpKNg4FH2rx3rM2rXDYFc+dXjZ4sqHUXVS2 vk0wx3tf3A1p11mcM505dNm4DvuIamZmTgo9mPfEplwX3nE3ZyBQLIo2i9W3XqTZJW2q 9GZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=sFlYEAQckeRXon3Gb7dVboi70GiJgP07IOxKz1DUs5s=; b=r8sMCEs5BhMxvBYxX/KITMZIoELvc7oj9U1fOqpnvnbfZ30cZqpb9nHgSLzHlxqSdM M6A8qByAf54l9Z4lAjDik1xj+ZKwlIgoiYKSuo8vzkmcbtoff6JHMZGABPbWE2yxSrzL oCIrtM71BxdJYZ1nzlkaZR5iKOu0i49VfnQDiYw2MgPw3HqhII4HaqRur2U1CfUDm/Wa YF4dgmbb4XeGQoQgRcDCVF8BgXJG3qSF6Ca8mGlMEOfG75t7tX/B1CAogprxebyQT9T4 mG4PHvudISO8tOw69kifaSxd+3rUiNXH960WF8ej5qJENZDZW/Ec+udvYdbG3CzKkCCW WLOQ== X-Gm-Message-State: AOAM530NATbZWlQA2CW2+n4AUEKFWpSBGF5GbW3qFustZNpGwozWt7uO +Wq3Tk3cmEskliF03MX9kEGWjA== X-Received: by 2002:a17:902:c94e:b0:151:a988:f3dd with SMTP id i14-20020a170902c94e00b00151a988f3ddmr18308247pla.142.1647150940242; Sat, 12 Mar 2022 21:55:40 -0800 (PST) Received: from localhost.localdomain (104.225.159.237.16clouds.com. [104.225.159.237]) by smtp.gmail.com with ESMTPSA id m11-20020a056a00080b00b004f75d5f9b5csm14792447pfk.26.2022.03.12.21.55.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Mar 2022 21:55:39 -0800 (PST) From: Leo Yan To: Sudeep Holla , Greg Kroah-Hartman , "Rafael J. Wysocki" , Vincent Guittot , Bryan O'Donoghue , linux-kernel@vger.kernel.org Cc: Leo Yan Subject: [PATCH v1 3/3] arch_topology: Scale CPU capacity if without CPU raw capacity Date: Sun, 13 Mar 2022 13:55:12 +0800 Message-Id: <20220313055512.248571-4-leo.yan@linaro.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220313055512.248571-1-leo.yan@linaro.org> References: <20220313055512.248571-1-leo.yan@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Unlike a typical Arm big.LITTLE architecture, some Arm systems (like Qualcomm SoC msm8996 and msm8939) have two clusters, all CPUs in two clusters have the same micro architecture, but some CPUs are "fast" and other are "slow". On this kind platform, all CPUs have the same raw CPU capacity but "fast" CPUs have higher maximum frequency than "slow" ones. Let's see an example, there have two clusters and every cluster have 4 CPUs, every CPU has the same raw CPU capacity. The cluster 0 has the maximum frequency 1497.6MHz and the cluster 1 has the maximum frequency 1113.6MHz, if don't specify "capacity-dmips-mhz" in DT, the we will get below result: # cat /sys/devices/system/cpu/cpu*/cpu_capacity 1024 1024 1024 1024 1024 1024 1024 1024 If "capacity-dmips-mhz" property is not specified for CPU nodes, the kernel will fallback to default capacity value SCHED_CAPACITY_SCALE (1024). Though CPUs in different clusters have different maximum frequencies, kernel skips to scale CPU capacity so that every CPU capacity is always SCHED_CAPACITY_SCALE (1024). This patch is to scale CPU capacity even though "capacity-dmips-mhz" property is not specified in DT. If "capacity-dmips-mhz" property is absent in DT binding, the array "raw_capacity" is not allocated so we rollback to use SCHED_CAPACITY_SCALE as raw CPU capacity and proceed to scale CPU capacity based on maximum frequency. After apply this patch, we can get below result for up elaborated platform: # cat /sys/devices/system/cpu/cpu*/cpu_capacity 1024 1024 1024 1024 761 761 761 761 Signed-off-by: Leo Yan --- drivers/base/arch_topology.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c index 0687576e880b..ef1fa2e417ea 100644 --- a/drivers/base/arch_topology.c +++ b/drivers/base/arch_topology.c @@ -267,20 +267,25 @@ void topology_normalize_cpu_scale(void) { u64 capacity; u64 capacity_scale; + u32 raw_cpu_capacity; int cpu; - if (!raw_capacity) + if (cap_parsing_failed) return; capacity_scale = 1; for_each_possible_cpu(cpu) { - capacity = raw_capacity[cpu] * per_cpu(freq_factor, cpu); + raw_cpu_capacity = + raw_capacity ? raw_capacity[cpu] : SCHED_CAPACITY_SCALE; + capacity = raw_cpu_capacity * per_cpu(freq_factor, cpu); capacity_scale = max(capacity, capacity_scale); } pr_debug("cpu_capacity: capacity_scale=%llu\n", capacity_scale); for_each_possible_cpu(cpu) { - capacity = raw_capacity[cpu] * per_cpu(freq_factor, cpu); + raw_cpu_capacity = + raw_capacity ? raw_capacity[cpu] : SCHED_CAPACITY_SCALE; + capacity = raw_cpu_capacity * per_cpu(freq_factor, cpu); capacity = div64_u64(capacity << SCHED_CAPACITY_SHIFT, capacity_scale); topology_set_cpu_scale(cpu, capacity); @@ -373,7 +378,7 @@ init_cpu_capacity_callback(struct notifier_block *nb, struct cpufreq_policy *policy = data; int cpu; - if (!raw_capacity) + if (cap_parsing_failed) return 0; if (val != CPUFREQ_CREATE_POLICY) @@ -412,7 +417,7 @@ static int __init register_cpufreq_notifier(void) * until we have the necessary code to parse the cpu capacity, so * skip registering cpufreq notifier. */ - if (!acpi_disabled || !raw_capacity) + if (!acpi_disabled || cap_parsing_failed) return -EINVAL; if (!alloc_cpumask_var(&cpus_to_visit, GFP_KERNEL)) -- 2.25.1