From: Sudeep Holla <sudeep.holla@arm.com>
To: Zeng Heng <zengheng4@huawei.com>
Cc: <broonie@kernel.org>, <joey.gouly@arm.com>, <will@kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>, <amit.kachhap@arm.com>,
<rafael@kernel.org>, <catalin.marinas@arm.com>,
<james.morse@arm.com>, <mark.rutland@arm.com>, <maz@kernel.org>,
<viresh.kumar@linaro.org>, <sumitg@nvidia.com>,
<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>
Subject: Re: [PATCH 2/3] cpufreq: CPPC: Keep the target core awake when reading its cpufreq rate
Date: Thu, 26 Oct 2023 09:53:21 +0100 [thread overview]
Message-ID: <ZTopAUnBQXGIuM5f@bogus> (raw)
In-Reply-To: <dcc4dfd7-fbef-7b46-5037-3916077ec696@huawei.com>
On Thu, Oct 26, 2023 at 10:24:54AM +0800, Zeng Heng wrote:
>
> 在 2023/10/25 19:13, Sudeep Holla 写道:
> > 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.
> > >
> > > Reported-by: Sumit Gupta <sumitg@nvidia.com>
> > > Link: https://lore.kernel.org/all/20230418113459.12860-7-sumitg@nvidia.com/
> > > Signed-off-by: Zeng Heng <zengheng4@huawei.com>
> > > ---
> > > 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
> > [...]
> >
> > > @@ -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))
> > Have you compiled this on x86 ? Even if you have somehow managed to,
> > this is not the right place to check the presence of AMU feature on
> > the CPU.
> > If AMU registers are used in CPPC, they must be using FFH GAS, in which
> > case the interpretation of FFH is architecture dependent code.
>
> According to drivers/cpufreq/Makefile, cppc_cpufreq.c is only compiled with
> ARM architecture.
>
Well that's true but this change doesn't belong to cppc_cpufreq.c, it must
be part of drivers/acpi/cppc_acpi.c IMO and sorry I assumed that without
explicitly mentioning that here.
> But here, I would change cpu_has_amu_feat() with cpc_ffh_supported(), which
> belongs to FFH APIs.
>
It is not like that. cppc_acpi.c will know the GAS is FFH based so no need to
check anything there. I see counters_read_on_cpu() called from cpc_ffh_read()
already takes care of reading the AMUs on the right CPU. What exactly is
the issue you are seeing ? I don't if this change is needed at all.
--
Regards,
Sudeep
WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Holla <sudeep.holla@arm.com>
To: Zeng Heng <zengheng4@huawei.com>
Cc: <broonie@kernel.org>, <joey.gouly@arm.com>, <will@kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>, <amit.kachhap@arm.com>,
<rafael@kernel.org>, <catalin.marinas@arm.com>,
<james.morse@arm.com>, <mark.rutland@arm.com>, <maz@kernel.org>,
<viresh.kumar@linaro.org>, <sumitg@nvidia.com>,
<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>
Subject: Re: [PATCH 2/3] cpufreq: CPPC: Keep the target core awake when reading its cpufreq rate
Date: Thu, 26 Oct 2023 09:53:21 +0100 [thread overview]
Message-ID: <ZTopAUnBQXGIuM5f@bogus> (raw)
In-Reply-To: <dcc4dfd7-fbef-7b46-5037-3916077ec696@huawei.com>
On Thu, Oct 26, 2023 at 10:24:54AM +0800, Zeng Heng wrote:
>
> 在 2023/10/25 19:13, Sudeep Holla 写道:
> > 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.
> > >
> > > Reported-by: Sumit Gupta <sumitg@nvidia.com>
> > > Link: https://lore.kernel.org/all/20230418113459.12860-7-sumitg@nvidia.com/
> > > Signed-off-by: Zeng Heng <zengheng4@huawei.com>
> > > ---
> > > 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
> > [...]
> >
> > > @@ -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))
> > Have you compiled this on x86 ? Even if you have somehow managed to,
> > this is not the right place to check the presence of AMU feature on
> > the CPU.
> > If AMU registers are used in CPPC, they must be using FFH GAS, in which
> > case the interpretation of FFH is architecture dependent code.
>
> According to drivers/cpufreq/Makefile, cppc_cpufreq.c is only compiled with
> ARM architecture.
>
Well that's true but this change doesn't belong to cppc_cpufreq.c, it must
be part of drivers/acpi/cppc_acpi.c IMO and sorry I assumed that without
explicitly mentioning that here.
> But here, I would change cpu_has_amu_feat() with cpc_ffh_supported(), which
> belongs to FFH APIs.
>
It is not like that. cppc_acpi.c will know the GAS is FFH based so no need to
check anything there. I see counters_read_on_cpu() called from cpc_ffh_read()
already takes care of reading the AMUs on the right CPU. What exactly is
the issue you are seeing ? I don't if this change is needed at all.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-10-26 8:53 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-25 9:38 [PATCH 0/3] Make the cpuinfo_cur_freq interface read correctly Zeng Heng
2023-10-25 9:38 ` Zeng Heng
2023-10-25 9:38 ` [PATCH 1/3] arm64: cpufeature: Export cpu_has_amu_feat() Zeng Heng
2023-10-25 9:38 ` Zeng Heng
2023-10-25 9:38 ` [PATCH 2/3] cpufreq: CPPC: Keep the target core awake when reading its cpufreq rate Zeng Heng
2023-10-25 9:38 ` Zeng Heng
2023-10-25 10:54 ` Mark Rutland
2023-10-25 10:54 ` Mark Rutland
2023-10-25 14:57 ` Sumit Gupta
2023-10-25 14:57 ` Sumit Gupta
2023-10-30 13:19 ` Beata Michalska
2023-10-30 13:19 ` Beata Michalska
2023-10-26 3:21 ` Zeng Heng
2023-10-26 3:21 ` Zeng Heng
2023-10-25 11:13 ` Sudeep Holla
2023-10-25 11:13 ` Sudeep Holla
2023-10-26 2:24 ` Zeng Heng
2023-10-26 2:24 ` Zeng Heng
2023-10-26 8:53 ` Sudeep Holla [this message]
2023-10-26 8:53 ` Sudeep Holla
2023-10-26 9:05 ` Zeng Heng
2023-10-26 9:05 ` Zeng Heng
2023-10-31 23:52 ` kernel test robot
2023-10-31 23:52 ` kernel test robot
2023-10-25 9:38 ` [PATCH 3/3] cpufreq: CPPC: Eliminate the impact of cpc_read() latency error Zeng Heng
2023-10-25 9:38 ` Zeng Heng
2023-10-25 11:01 ` Mark Rutland
2023-10-25 11:01 ` Mark Rutland
2023-10-26 1:55 ` Zeng Heng
2023-10-26 1:55 ` Zeng Heng
2023-10-26 11:26 ` Mark Rutland
2023-10-26 11:26 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZTopAUnBQXGIuM5f@bogus \
--to=sudeep.holla@arm.com \
--cc=amit.kachhap@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=joey.gouly@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=rafael@kernel.org \
--cc=sumitg@nvidia.com \
--cc=viresh.kumar@linaro.org \
--cc=wangxiongfeng2@huawei.com \
--cc=will@kernel.org \
--cc=xiexiuqi@huawei.com \
--cc=yang@os.amperecomputing.com \
--cc=zengheng4@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.