Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp5294004rwr; Mon, 24 Apr 2023 01:43:23 -0700 (PDT) X-Google-Smtp-Source: AKy350a42J8x+AsyH8a/CalB7cvr0Lvae2F9qZOQSC9Gx7R7i/wtUsPN7AlWkS7JqKcH2N0r1oL2 X-Received: by 2002:a17:902:ecc6:b0:1a0:422f:39d9 with SMTP id a6-20020a170902ecc600b001a0422f39d9mr15957862plh.39.1682325802984; Mon, 24 Apr 2023 01:43:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682325802; cv=none; d=google.com; s=arc-20160816; b=wQxFqfRjFyLTY9vlbcGpzAD6TOR5xSD94o6godPjgpxO7WyONnql3C+4xh/tfP/gu2 tsdzFbtaRmbR0ocfV3luT9uRAyW/+VEWejN6CNYHEmHYxc7HO+v9MVKjn9Z1JWqpATMt kkT5ZqH5jPtTRzf4upe6tarPeqsOEpYj32P6xol4i06S3U2S3gffi6mXzFQu784i8Q5/ vLuF/tfKdJB6IHXpEEM6rEaYgm1A0JNzswhioSzmmBbE52Q2fvPpUNB3XJ/LhIAO3pHM NvztW/SoVgeb3LokYSQCIkvZ0oQiFOiJ/pob3wIwMYbf8qA8fk2n8rqYRQeI21mAKI/B XGxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=MQ0wZVEHz3eT+aqLQakyO1+4QEDuPtY0abaTwwiursM=; b=rZFcSN5PJ4PzQpVMF0HC4xe5gcPZMlTosiHP5RieLKw+ydsaqC4UrMkK5979u5XJoW lO6MXCLvdWc9P9boEKbs9H4qz2wp25IRMhsouYuG4CM9LMYQ/HqCFsX2cdqpv7bmzM0a mJ4DJRsBhu0Ba/6LMYPcL7oBkOFfTlyERq+AvrtXayaCHfayGnMh4u3oSoMH+TMywKk9 aPizvDE/wAYDcMPwh2s9N4ZMb7GzxzXn1QtxaJUeeQ7UYNlOSKSpv1AL9X1ukutXiDcB tUBGkKfQteuC4pR+qoscvHroIA72YaFav+HxTksutq0sSLJxUJLaaZOUq+MuoilZ7vES 3GQg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i9-20020a17090332c900b001a6b78ede3dsi11327009plr.581.2023.04.24.01.43.09; Mon, 24 Apr 2023 01:43:22 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230152AbjDXIcW (ORCPT + 99 others); Mon, 24 Apr 2023 04:32:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59904 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229507AbjDXIcV (ORCPT ); Mon, 24 Apr 2023 04:32:21 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 60FF21AD; Mon, 24 Apr 2023 01:32:19 -0700 (PDT) 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 84820D75; Mon, 24 Apr 2023 01:33:02 -0700 (PDT) Received: from localhost (ionvoi01-desktop.cambridge.arm.com [10.2.78.69]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3BF913F5A1; Mon, 24 Apr 2023 01:32:18 -0700 (PDT) Date: Mon, 24 Apr 2023 09:32:16 +0100 From: Ionela Voinescu To: Sumit Gupta Cc: viresh.kumar@linaro.org, rafael@kernel.org, mark.rutland@arm.com, sudeep.holla@arm.com, lpieralisi@kernel.org, catalin.marinas@arm.com, will@kernel.org, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org, treding@nvidia.com, jonathanh@nvidia.com, vsethi@nvidia.com, sdonthineni@nvidia.com, sanjayc@nvidia.com, ksitaraman@nvidia.com, bbasu@nvidia.com Subject: Re: [Patch 6/6] cpufreq: CPPC: use wq to read amu counters on target cpu Message-ID: References: <20230418113459.12860-1-sumitg@nvidia.com> <20230418113459.12860-7-sumitg@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230418113459.12860-7-sumitg@nvidia.com> X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,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 Hi Sumit, Thank you for the patches! On Tuesday 18 Apr 2023 at 17:04:59 (+0530), Sumit Gupta wrote: > ARM cores which implement the Activity Monitor Unit (AMU) > use Functional Fixed Hardware (FFH) to map AMU counters to > Delivered_Counter and Reference_Counter registers. Each > sysreg is read separately with a smp_call_function_single > call. So, total four IPI's are used, one per register. > Due to this, the AMU's core counter and constant counter > sampling can happen at a non-consistent time interval if > an IPI is handled late. This results in unstable frequency > value from "cpuinfo_cur_req" node sometimes. To fix, queue > work on target CPU to read all counters synchronously in > sequence. This helps to remove the inter-IPI latency and > make sure that both the counters are sampled at a close > time interval. > Without this change we observed that the re-generated value > of CPU Frequency from AMU counters sometimes deviates by > ~25% as the counters are read at non-determenistic time. > Currently, kept the change specific to Tegra241. It can be > applied to other SoC's having AMU if same issue is observed. > To be honest I never liked the need for IPIs but it was the most generic solution I could find for an FFH implementation that does not assume a dependency between different reads, which is usecase specific. Also, for any kind of caching of the counters I'd have to introduce some logic that would assume we'd always have two consecutive reads - one for the cycle counter and one for the constant counter, and there should be no update between them. And then there's the problem of potentially returning the same values if there's no update between two sets of reads. The only feasible idea based on caching would be to piggy back on the frequency invariance engine (FIE) which computes a performance scale factor on the tick which can be translated to frequency. But the frequency obtained would be an average frequency for the past 4ms, which can in turn be at up to 4ms old (or more, if the CPU was idle). Would something like this work for you? This could also help with a similar issue described at [1] - not an IPI related issue, but an issue with similar symptoms. [1] https://lore.kernel.org/lkml/20230328193846.8757-1-yang@os.amperecomputing.com/ Thanks, Ionela. > Signed-off-by: Sumit Gupta > --- > drivers/cpufreq/cppc_cpufreq.c | 53 +++++++++++++++++++++++++++------- > 1 file changed, 43 insertions(+), 10 deletions(-) > > diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c > index 5e6a132a525e..52b93ac6225e 100644 > --- a/drivers/cpufreq/cppc_cpufreq.c > +++ b/drivers/cpufreq/cppc_cpufreq.c > @@ -46,6 +46,8 @@ static bool boost_supported; > /* default 2usec delay between sampling */ > static unsigned int sampling_delay_us = 2; > > +static bool get_rate_use_wq; > + > static void cppc_check_hisi_workaround(void); > static void cppc_nvidia_workaround(void); > > @@ -99,6 +101,12 @@ struct cppc_freq_invariance { > static DEFINE_PER_CPU(struct cppc_freq_invariance, cppc_freq_inv); > static struct kthread_worker *kworker_fie; > > +struct feedback_ctrs { > + u32 cpu; > + struct cppc_perf_fb_ctrs fb_ctrs_t0; > + struct cppc_perf_fb_ctrs fb_ctrs_t1; > +}; > + > static unsigned int hisi_cppc_cpufreq_get_rate(unsigned int cpu); > static int cppc_perf_from_fbctrs(struct cppc_cpudata *cpu_data, > struct cppc_perf_fb_ctrs *fb_ctrs_t0, > @@ -851,28 +859,44 @@ static int cppc_perf_from_fbctrs(struct cppc_cpudata *cpu_data, > return (reference_perf * delta_delivered) / delta_reference; > } > > +static int cppc_get_perf_ctrs_sync(void *fb_ctrs) > +{ > + struct feedback_ctrs *ctrs = fb_ctrs; > + int ret; > + > + ret = cppc_get_perf_ctrs(ctrs->cpu, &(ctrs->fb_ctrs_t0)); > + if (ret) > + return ret; > + > + udelay(sampling_delay_us); > + > + ret = cppc_get_perf_ctrs(ctrs->cpu, &(ctrs->fb_ctrs_t1)); > + if (ret) > + return ret; > + > + return ret; > +} > + > static unsigned int cppc_cpufreq_get_rate(unsigned int cpu) > { > - struct cppc_perf_fb_ctrs fb_ctrs_t0 = {0}, fb_ctrs_t1 = {0}; > struct cpufreq_policy *policy = cpufreq_cpu_get(cpu); > struct cppc_cpudata *cpu_data = policy->driver_data; > + struct feedback_ctrs fb_ctrs = {0}; > u64 delivered_perf; > int ret; > > cpufreq_cpu_put(policy); > + fb_ctrs.cpu = cpu; > > - ret = cppc_get_perf_ctrs(cpu, &fb_ctrs_t0); > - if (ret) > - return ret; > - > - udelay(sampling_delay_us); > - > - ret = cppc_get_perf_ctrs(cpu, &fb_ctrs_t1); > + if (get_rate_use_wq) > + ret = smp_call_on_cpu(cpu, cppc_get_perf_ctrs_sync, &fb_ctrs, false); > + else > + ret = cppc_get_perf_ctrs_sync(&fb_ctrs); > if (ret) > return ret; > > - delivered_perf = cppc_perf_from_fbctrs(cpu_data, &fb_ctrs_t0, > - &fb_ctrs_t1); > + delivered_perf = cppc_perf_from_fbctrs(cpu_data, &(fb_ctrs.fb_ctrs_t0), > + &(fb_ctrs.fb_ctrs_t1)); > > return cppc_cpufreq_perf_to_khz(cpu_data, delivered_perf); > } > @@ -953,7 +977,16 @@ static unsigned int hisi_cppc_cpufreq_get_rate(unsigned int cpu) > > static void cppc_nvidia_workaround(void) > { > + int cpu; > + > sampling_delay_us = 25; > + > +#ifdef CONFIG_ARM64_AMU_EXTN > + cpu = get_cpu_with_amu_feat(); > + > + if (cpu < nr_cpu_ids) > + get_rate_use_wq = true; > +#endif > } > > static void cppc_check_hisi_workaround(void) > -- > 2.17.1 >