Received: by 2002:a05:7412:a9a2:b0:e2:908c:2ebd with SMTP id o34csp2733910rdh; Mon, 30 Oct 2023 06:20:15 -0700 (PDT) X-Google-Smtp-Source: AGHT+IECSN8wna5t7U/2yilKmP8U+HVNjG888C1gSN/RrO4hc59VmS/1wC8h0BeIfXmegXksLrvp X-Received: by 2002:a05:6358:51dc:b0:166:cc78:ee9b with SMTP id 28-20020a05635851dc00b00166cc78ee9bmr8797075rwl.8.1698672015067; Mon, 30 Oct 2023 06:20:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698672015; cv=none; d=google.com; s=arc-20160816; b=p736Ixnk2vsqjPXfiNZ61i9yL5DC2IjTLG0D6Q0Rd3ZT1PUXP6xpes8eFv16xepDrR PXPJnfKJ4wK9elXXRJeyIc3QlGXZ37/A/+SwbAhxkCOzYVrOoZJ0pQ4fsDfr3RIIfKi8 vePOcQ2ElGYW65SNfbUY79PJaC2LZa0uKEXigWcX0q+2L0ecY6Ygv7Igfg4sI2X46vvA CZq+KDpls6da6p7GTPY0aCTZhv/2lCIjZPbXAijxlnT7qA0a1B61ccplR7dnvTF+Ll8N EzTsvYoPt2V7SWECYVsYNHUvUyuZY+jsdX5YaNyL7352BeqWHBHccqJdEEqRHlEggXNs KSzQ== 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=VSFnduAe9fzOQykIsDTaRK4qyVfNT/b6i8dC1UwjE/8=; fh=+Wxgpc4v5do+TnDdftWoERntL2/5g/92ilAvWHLSMUw=; b=mAmebNFmLzg7W79mgxhsk9gpjQBEgldVULHo4EDlxBCPypGr8XVcFJmD+NYdZdi3YP v5AnwIPeZ077p690RZdg/hVruYWCcv5pepTtn2TZMN2S5WH7Z8vMq+ECrRrHKO/OVQv/ JFNgNmOziZWcouWdQamrQozahKxAerX8QsHzC8NsdoMqjah+pEHxHHr+FnNYrVSqG2lK 8rAZ19EJRTkC626cpxIVb7OQOwX6qIuAdfuVVB38Z/Y/98s+UR7iyI2HN0xhGFp0+OYH 0MEyLvqGBBEFnOQ2x7HfJHguZpV9SHGT1TKAOcpA6wO8czfK7zyb24W3o9uNWxLMdZNT VAzw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 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 groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id i3-20020a639d03000000b005b9022ddeb9si4861370pgd.501.2023.10.30.06.20.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Oct 2023 06:20:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id EA5118062091; Mon, 30 Oct 2023 06:20:11 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233333AbjJ3NUD (ORCPT + 99 others); Mon, 30 Oct 2023 09:20:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44316 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232176AbjJ3NUB (ORCPT ); Mon, 30 Oct 2023 09:20:01 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D1301C9; Mon, 30 Oct 2023 06:19:58 -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 1DFABFEC; Mon, 30 Oct 2023 06:20:40 -0700 (PDT) Received: from e129154.nice.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 F25103F64C; Mon, 30 Oct 2023 06:19:53 -0700 (PDT) Date: Mon, 30 Oct 2023 14:19:06 +0100 From: Beata Michalska To: Sumit Gupta Cc: Zeng Heng , broonie@kernel.org, joey.gouly@arm.com, will@kernel.org, amit.kachhap@arm.com, rafael@kernel.org, catalin.marinas@arm.com, james.morse@arm.com, maz@kernel.org, viresh.kumar@linaro.org, yang@os.amperecomputing.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, wangxiongfeng2@huawei.com, xiexiuqi@huawei.com, Ionela Voinescu , linux-tegra , Mark Rutland Subject: Re: [PATCH 2/3] cpufreq: CPPC: Keep the target core awake when reading its cpufreq rate Message-ID: References: <20231025093847.3740104-1-zengheng4@huawei.com> <20231025093847.3740104-3-zengheng4@huawei.com> <28a6e60c-4492-105b-5fcf-3129ca868349@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28a6e60c-4492-105b-5fcf-3129ca868349@nvidia.com> X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Mon, 30 Oct 2023 06:20:12 -0700 (PDT) On Wed, Oct 25, 2023 at 08:27:23PM +0530, Sumit Gupta wrote: > > > > > [adding Ionela] > > > > On Wed, Oct 25, 2023 at 05:38:46PM +0800, Zeng Heng wrote: > > > As ARM AMU's document says, all counters are subject to any changes > > > in clock frequency, including clock stopping caused by the WFI and WFE > > > instructions. > > > > > > Therefore, using smp_call_on_cpu() to trigger target CPU to > > > read self's AMU counters, which ensures the counters are working > > > properly while cstate feature is enabled. > > > > IIUC there's a pretty deliberate split with all the actual reading of the AMU > > living in arch/arm64/kernel/topolgy.c, and the driver code being (relatively) > > generic. > > > > We already have code in arch/arm64/kernel/topolgy.c to read counters on a > > specific CPU; why can't e reuse that (and avoid exporting cpu_has_amu_feat())? > > > This patch seems mostly based on my previous patch [1] and discussed here > [2] already. Beata [CCed] shared an alternate approach [3] leveraging > existing code from 'topology.c' to get the average freq for last tick > period. > > > Beata, > > Could you share v2 of [3] with the request to merge. We can try to solve the > issue with CPU IDLE case later on top? > Will do (same for the below request if feasible) --- BR B. > Additionally, also please include the fix in [4] if it looks fine. > > Best Regards, > Sumit Gupta > > [1] https://lore.kernel.org/all/20230418113459.12860-7-sumitg@nvidia.com/ > [2] https://lore.kernel.org/lkml/cde1d8a9-3a21-e82b-7895-40603a14d898@nvidia.com/T/#m2174305de4706006e0bd9c103a0e5ff61cea7a12 > [3] > https://lore.kernel.org/lkml/20230606155754.245998-1-beata.michalska@arm.com/ > [4] > https://lore.kernel.org/lkml/6a5710f6-bfbb-5dfd-11cd-0cd02220cee7@nvidia.com/ > > > > > > > > Reported-by: Sumit Gupta > > > Link: https://lore.kernel.org/all/20230418113459.12860-7-sumitg@nvidia.com/ > > > Signed-off-by: Zeng Heng > > > --- > > > drivers/cpufreq/cppc_cpufreq.c | 39 ++++++++++++++++++++++++++-------- > > > 1 file changed, 30 insertions(+), 9 deletions(-) > > > > > > diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c > > > index fe08ca419b3d..321a9dc9484d 100644 > > > --- a/drivers/cpufreq/cppc_cpufreq.c > > > +++ b/drivers/cpufreq/cppc_cpufreq.c > > > @@ -90,6 +90,12 @@ static int cppc_perf_from_fbctrs(struct cppc_cpudata *cpu_data, > > > struct cppc_perf_fb_ctrs *fb_ctrs_t0, > > > struct cppc_perf_fb_ctrs *fb_ctrs_t1); > > > > > > +struct fb_ctr_pair { > > > + u32 cpu; > > > + struct cppc_perf_fb_ctrs fb_ctrs_t0; > > > + struct cppc_perf_fb_ctrs fb_ctrs_t1; > > > +}; > > > + > > > /** > > > * cppc_scale_freq_workfn - CPPC arch_freq_scale updater for frequency invariance > > > * @work: The work item. > > > @@ -840,9 +846,24 @@ static int cppc_perf_from_fbctrs(struct cppc_cpudata *cpu_data, > > > return (reference_perf * delta_delivered) / delta_reference; > > > } > > > > > > +static int cppc_get_perf_ctrs_pair(void *val) > > > +{ > > > + struct fb_ctr_pair *fb_ctrs = val; > > > + int cpu = fb_ctrs->cpu; > > > + int ret; > > > + > > > + ret = cppc_get_perf_ctrs(cpu, &fb_ctrs->fb_ctrs_t0); > > > + if (ret) > > > + return ret; > > > + > > > + udelay(2); /* 2usec delay between sampling */ > > > + > > > + return cppc_get_perf_ctrs(cpu, &fb_ctrs->fb_ctrs_t1); > > > +} > > > + > > > static unsigned int cppc_cpufreq_get_rate(unsigned int cpu) > > > { > > > - struct cppc_perf_fb_ctrs fb_ctrs_t0 = {0}, fb_ctrs_t1 = {0}; > > > + struct fb_ctr_pair fb_ctrs = { .cpu = cpu, }; > > > struct cpufreq_policy *policy = cpufreq_cpu_get(cpu); > > > struct cppc_cpudata *cpu_data = policy->driver_data; > > > u64 delivered_perf; > > > @@ -850,18 +871,18 @@ static unsigned int cppc_cpufreq_get_rate(unsigned int cpu) > > > > > > cpufreq_cpu_put(policy); > > > > > > - ret = cppc_get_perf_ctrs(cpu, &fb_ctrs_t0); > > > - if (ret) > > > - return 0; > > > - > > > - udelay(2); /* 2usec delay between sampling */ > > > + if (cpu_has_amu_feat(cpu)) > > > + ret = smp_call_on_cpu(cpu, cppc_get_perf_ctrs_pair, > > > + &fb_ctrs, false); > > > + else > > > + ret = cppc_get_perf_ctrs_pair(&fb_ctrs); > > > > > > - ret = cppc_get_perf_ctrs(cpu, &fb_ctrs_t1); > > > if (ret) > > > return 0; > > > > > > - 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); > > > } > > > -- > > > 2.25.1 > > >