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 594B1C3DA4B for ; Wed, 17 Jul 2024 06:55:59 +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:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=z/D3vCK20VkMavMtMZMIeuDFrrRChNkcWF+1VrqypfA=; b=1/mzNZGW7mC4k3BU6PrcJq9Cfg pn4/VmoHhJCRY+uoctXyK+lO3ZG7ycFnFe2b9dagPLMRzuoNRZaAXumTJ0T5Qt07YFc0BgdnJUlrO MoqH0UcVbGYD3xsJVzZejRcSHks47Qd8p/bMZ/A4acmwMhaG2QgGJl8NDti2hu7zMO3OaM0vw/mnQ N5ckWxT8r7SVNOLRFMn1ir2sypvfixPoXnIW96W681ju5wsHtaXk8eeE+5yAi6Yatn8jQoaUjSqgC igV/6ljTcUP2AWXmKfXyLP1A/rTeATqqEovejWxnA+B/GJrUen9KV8SygL5EcbiOfn1nNAU2IsAeG FkItOd7g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sTyZj-0000000CuTZ-0iyR; Wed, 17 Jul 2024 06:55:43 +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 1sTyZM-0000000CuOz-1qxJ for linux-arm-kernel@lists.infradead.org; Wed, 17 Jul 2024 06:55:23 +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 3CB1F1063; Tue, 16 Jul 2024 23:55:42 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B83913F762; Tue, 16 Jul 2024 23:55:13 -0700 (PDT) Date: Wed, 17 Jul 2024 08:54:58 +0200 From: Beata Michalska To: Vanshidhar Konda Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, ionela.voinescu@arm.com, sudeep.holla@arm.com, will@kernel.org, catalin.marinas@arm.com, vincent.guittot@linaro.org, sumitg@nvidia.com, yang@os.amperecomputing.com, lihuisong@huawei.com, viresh.kumar@linaro.org, rafael@kernel.org Subject: Re: [PATCH v6 3/4] arm64: Provide an AMU-based version of arch_freq_get_on_cpu Message-ID: References: <20240603082154.3830591-1-beata.michalska@arm.com> <20240603082154.3830591-4-beata.michalska@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240716_235520_635483_EF356FFE X-CRM114-Status: GOOD ( 43.04 ) 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 On Wed, Jul 10, 2024 at 10:44:41AM -0700, Vanshidhar Konda wrote: > I apologize for the late review. This series dropped off my radar. I will test > this on an AmpereOne system. > > On Mon, Jun 03, 2024 at 09:21:53AM +0100, Beata Michalska wrote: > > With the Frequency Invariance Engine (FIE) being already wired up with > > sched tick and making use of relevant (core counter and constant > > counter) AMU counters, getting the current frequency for a given CPU, > > can be achieved by utilizing the frequency scale factor which reflects > > an average CPU frequency for the last tick period length. > > > > The solution is partially based on APERF/MPERF implementation of > > arch_freq_get_on_cpu. > > > > Suggested-by: Ionela Voinescu > > Signed-off-by: Beata Michalska > > --- > > arch/arm64/kernel/topology.c | 110 +++++++++++++++++++++++++++++++---- > > 1 file changed, 100 insertions(+), 10 deletions(-) > > > > diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c > > index e475ec2705e1..2c002d2c3e0b 100644 > > --- a/arch/arm64/kernel/topology.c > > +++ b/arch/arm64/kernel/topology.c > > @@ -17,6 +17,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include > > @@ -88,18 +89,28 @@ int __init parse_acpi_topology(void) > > * initialized. > > */ > > static DEFINE_PER_CPU_READ_MOSTLY(unsigned long, arch_max_freq_scale) = 1UL << (2 * SCHED_CAPACITY_SHIFT); > > -static DEFINE_PER_CPU(u64, arch_const_cycles_prev); > > -static DEFINE_PER_CPU(u64, arch_core_cycles_prev); > > static cpumask_var_t amu_fie_cpus; > > > > +struct amu_cntr_sample { > > + u64 arch_const_cycles_prev; > > + u64 arch_core_cycles_prev; > > + unsigned long last_update; > > +}; > > + > > +static DEFINE_PER_CPU_SHARED_ALIGNED(struct amu_cntr_sample, cpu_amu_samples); > > + > > void update_freq_counters_refs(void) > > Could this be renamed to update_amu_cntr_sample() for more clarity? I guess it could though to be fair I'd be more inclined to rename the struct itself: this function updates the cached counter values that are being used as a most recent ones but also as reference when calculating the delta between the readings, so I'd say the naming here is pretty accurate. > > > { > > - this_cpu_write(arch_core_cycles_prev, read_corecnt()); > > - this_cpu_write(arch_const_cycles_prev, read_constcnt()); > > + struct amu_cntr_sample *amu_sample = this_cpu_ptr(&cpu_amu_samples); > > + > > + amu_sample->arch_core_cycles_prev = read_corecnt(); > > + amu_sample->arch_const_cycles_prev = read_constcnt(); > > I think it would be better to update amp_sample->last_update here. update_freq_counters_refs > is the only way to update the amu_sample. So it should be safer to update the whole structure > in this method. Right, so the amu_sample->last_update is actually referring to updating the scale factor, not the counter values per-se, even though one cannot be updated without the other; so I'd rather keep those separated: the update time is being used to determine whether the last known freq scale is still somewhat relevant. If that would eliminate the confusion I can rename that filed. > > > } > > > > static inline bool freq_counters_valid(int cpu) > > { > > + struct amu_cntr_sample *amu_sample = per_cpu_ptr(&cpu_amu_samples, cpu); > > + > > if ((cpu >= nr_cpu_ids) || !cpumask_test_cpu(cpu, cpu_present_mask)) > > return false; > > > > @@ -108,8 +119,8 @@ static inline bool freq_counters_valid(int cpu) > > return false; > > } > > > > - if (unlikely(!per_cpu(arch_const_cycles_prev, cpu) || > > - !per_cpu(arch_core_cycles_prev, cpu))) { > > + if (unlikely(!amu_sample->arch_const_cycles_prev || > > + !amu_sample->arch_core_cycles_prev)) { > > pr_debug("CPU%d: cycle counters are not enabled.\n", cpu); > > return false; > > } > > @@ -152,17 +163,22 @@ void freq_inv_set_max_ratio(int cpu, u64 max_rate) > > > > static void amu_scale_freq_tick(void) > > { > > + struct amu_cntr_sample *amu_sample = this_cpu_ptr(&cpu_amu_samples); > > u64 prev_core_cnt, prev_const_cnt; > > u64 core_cnt, const_cnt, scale; > > > > - prev_const_cnt = this_cpu_read(arch_const_cycles_prev); > > - prev_core_cnt = this_cpu_read(arch_core_cycles_prev); > > + prev_const_cnt = amu_sample->arch_const_cycles_prev; > > + prev_core_cnt = amu_sample->arch_core_cycles_prev; > > > > update_freq_counters_refs(); > > > > - const_cnt = this_cpu_read(arch_const_cycles_prev); > > - core_cnt = this_cpu_read(arch_core_cycles_prev); > > + const_cnt = amu_sample->arch_const_cycles_prev; > > + core_cnt = amu_sample->arch_core_cycles_prev; > > > > + /* > > + * This should not happen unless the AMUs have been reset and the > > + * counter values have not been restored - unlikely > > + */ > > if (unlikely(core_cnt <= prev_core_cnt || > > const_cnt <= prev_const_cnt)) > > return; > > @@ -182,6 +198,8 @@ static void amu_scale_freq_tick(void) > > > > scale = min_t(unsigned long, scale, SCHED_CAPACITY_SCALE); > > this_cpu_write(arch_freq_scale, (unsigned long)scale); > > + > > + amu_sample->last_update = jiffies; > > Please see the comment above. I think this line could be moved to > update_freq_counters_refs method. > > > } > > > > static struct scale_freq_data amu_sfd = { > > @@ -189,6 +207,78 @@ static struct scale_freq_data amu_sfd = { > > .set_freq_scale = amu_scale_freq_tick, > > }; > > > > +static __always_inline bool amu_fie_cpu_supported(unsigned int cpu) > > +{ > > + return cpumask_available(amu_fie_cpus) && > > + cpumask_test_cpu(cpu, amu_fie_cpus); > > +} > > + > > +#define AMU_SAMPLE_EXP_MS 20 > > + > > +unsigned int arch_freq_get_on_cpu(int cpu) > > +{ > > + struct amu_cntr_sample *amu_sample; > > + unsigned int start_cpu = cpu; > > + unsigned long last_update; > > + unsigned int freq = 0; > > + u64 scale; > > + > > + if (!amu_fie_cpu_supported(cpu) || !arch_scale_freq_ref(cpu)) > > + return 0; > > + > > +retry: > > + amu_sample = per_cpu_ptr(&cpu_amu_samples, cpu); > > + > > + last_update = amu_sample->last_update; > > + > > + /* > > + * For those CPUs that are in full dynticks mode, > > + * and those that have not seen tick for a while > > + * try an alternative source for the counters (and thus freq scale), > > + * if available, for given policy: > > + * this boils down to identifying an active cpu within the same freq > > + * domain, if any. > > + */ > > + if (!housekeeping_cpu(cpu, HK_TYPE_TICK) || > > + time_is_before_jiffies(last_update + msecs_to_jiffies(AMU_SAMPLE_EXP_MS))) { > > + struct cpufreq_policy *policy = cpufreq_cpu_get(cpu); > > + int ref_cpu = cpu; > > + > > + if (!policy) > > + goto leave; > > + > > + if (!policy_is_shared(policy)) { > > + cpufreq_cpu_put(policy); > > + goto leave; > > + } > > + > > + do { > > + ref_cpu = cpumask_next_wrap(ref_cpu, policy->cpus, > > + start_cpu, false); > > + > > + } while (ref_cpu < nr_cpu_ids && idle_cpu(ref_cpu)); > > + > > + cpufreq_cpu_put(policy); > > + > > + if (ref_cpu >= nr_cpu_ids) > > + /* No alternative to pull info from */ > > + goto leave; > > + > > + cpu = ref_cpu; > > + goto retry; > > + } > > + /* > > + * Reversed computation to the one used to determine > > + * the arch_freq_scale value > > + * (see amu_scale_freq_tick for details) > > + */ > > + scale = arch_scale_freq_capacity(cpu); > > + freq = scale * arch_scale_freq_ref(cpu); > > + freq >>= SCHED_CAPACITY_SHIFT; > > +leave: > > + return freq; > > +} > > + > > static void amu_fie_setup(const struct cpumask *cpus) > > { > > int cpu; > > -- > > 2.25.1 > >