From patchwork Fri Sep 13 13:29:40 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Beata Michalska X-Patchwork-Id: 13803454 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 A4C5AFA3754 for ; Fri, 13 Sep 2024 13:31:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: MIME-Version:Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-Type: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=MPxZZid0HSXqZZtK4qSXbcC6UP3Z+U3wxXdP1cexSx4=; b=VwT7HE0yXZZzeOOUlLOiHnVqhv Jm4d9J18YXhEz2GPJYtSrpyoocvjZyvjUruC1yz3LSWO2XYIK+/aimlP/oS0xGgZkaj0ndqmKEFv7 a2gURnEwHcSDNANNlee7hvcMuUD9M+wYPBlxoAF+MNocFK77zcXIRjPsRDH9pYHw7nwaxQsSPF8sn m9FHz9zri7L6nPfQL+DBrKvqSTKtuO1/lFLotietnHewD5xSe1qAiNbwBZhjJsrNA2wKrTEUdqhNd Ck5hybpCCuv8UEx5G2Wc8I1Ebu0pmrSgFKuohEawlvH1SNmqN2XlRbBbSc+KTGsOcftqkl+qYtaw5 61/06l7w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sp6OO-0000000G2ET-2tRM; Fri, 13 Sep 2024 13:31:20 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sp6NI-0000000G1zq-3eZ7 for linux-arm-kernel@lists.infradead.org; Fri, 13 Sep 2024 13:30:14 +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 9F74213D5; Fri, 13 Sep 2024 06:30:39 -0700 (PDT) Received: from e125905.cambridge.arm.com (e125905.cambridge.arm.com [10.1.194.73]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 83D743F73B; Fri, 13 Sep 2024 06:30:08 -0700 (PDT) From: Beata Michalska To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, ionela.voinescu@arm.com, sudeep.holla@arm.com, will@kernel.org, catalin.marinas@arm.com, rafael@kernel.org, viresh.kumar@linaro.org Cc: sumitg@nvidia.com, yang@os.amperecomputing.com, vanshikonda@os.amperecomputing.com, lihuisong@huawei.com, zhanjie9@hisilicon.com Subject: [PATCH v7 0/4] Add support for AArch64 AMUv1-based average freq Date: Fri, 13 Sep 2024 14:29:40 +0100 Message-Id: <20240913132944.1880703-1-beata.michalska@arm.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240913_063013_017439_D9996240 X-CRM114-Status: GOOD ( 18.21 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi All, This series adds support for obtaining an average CPU frequency based on a hardware provided feedback. The average frequency is being exposed via dedicated yet optional cpufreq sysfs attribute - cpuinfo_avg_freq. The architecture specific bits are being provided for AArch64, caching on existing implementation for FIE and AMUv1 support: the frequency scale factor, updated on each sched tick, serving as a base for retrieving the frequency for a given CPU, representing an average frequency reported between the ticks. The changes have been rather lightly (due to some limitations) tested on an FVP model. Note that some small discrepancies have been observed while testing (on the model) and this is currently being investigated, though it should not have any significant impact on the overall results. Note that [PATCH 2/4] arm64: amu: Delay allocating cpumask for AMU FIE support can be merged independently. Relevant discussions: [1] https://lore.kernel.org/all/20240229162520.970986-1-vanshikonda@os.amperecomputing.com/ [2] https://lore.kernel.org/all/7eozim2xnepacnnkzxlbx34hib4otycnbn4dqymfziqou5lw5u@5xzpv3t7sxo3/ [3] https://lore.kernel.org/all/20231212072617.14756-1-lihuisong@huawei.com/ [4] https://lore.kernel.org/lkml/ZIHpd6unkOtYVEqP@e120325.cambridge.arm.com/T/#m4e74cb5a0aaa353c60fedc6cfb95ab7a6e381e3c [5] https://lore.kernel.org/all/20240603081331.3829278-1-beata.michalska@arm.com/ v7: - Dropping 'arch_topology: init capacity_freq_ref to 0' patch from the series as this one has been sent separately as an independent change [https://lore.kernel.org/all/20240827154818.1195849-1-ionela.voinescu@arm.com/] - Including in the series change that introduces new sysfs entry [PATCH 1/4] - Consequently modifying previously arch_freq_get_on_cpu to match reqs for new sysfs attribute - Dropping an idea of considering a CPU that has been idle for a while as a valid source of information for obtaining an AMU-counter based frequency - Some minor cosmetic changes v6: - delay allocating cpumask for AMU FIE support instead of invalidating the mask upon failure to register cpufreq policy notifications - drop the change to cpufreq core (for cpuinfo_cur_freq) as this one will be sent as a separate change v5: - Fix invalid access to cpumask - Reworked finding reference cpu when getting the freq v4: - dropping seqcount - fixing identifying active cpu within given policy - skipping full dynticks cpus when retrieving the freq - bringing back plugging in arch_freq_get_on_cpu into cpuinfo_cur_freq v3: - dropping changes to cpufreq_verify_current_freq - pulling in changes from Ionela initializing capacity_freq_ref to 0 (thanks for that!) and applying suggestions made by her during last review: - switching to arch_scale_freq_capacity and arch_scale_freq_ref when reversing freq scale factor computation - swapping shift with multiplication - adding time limit for considering last scale update as valid - updating frequency scale factor upon entering idle v2: - Splitting the patches - Adding comment for full dyntick mode - Plugging arch_freq_get_on_cpu into cpufreq_verify_current_freq instead of in show_cpuinfo_cur_freq to allow the framework to stay more in sync with potential freq changes Beata Michalska (4): cpufreq: Introduce an optional cpuinfo_avg_freq sysfs entry arm64: amu: Delay allocating cpumask for AMU FIE support arm64: Provide an AMU-based version of arch_freq_avg_get_on_cpu arm64: Update AMU-based freq scale factor on entering idle Documentation/admin-guide/pm/cpufreq.rst | 10 ++ arch/arm64/kernel/topology.c | 144 +++++++++++++++++++---- drivers/cpufreq/cpufreq.c | 31 +++++ include/linux/cpufreq.h | 1 + 4 files changed, 164 insertions(+), 22 deletions(-)