From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Doug Smythies <dsmythies@telus.net>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-pm@vger.kernel.org,
"the arch/x86 maintainers" <x86@kernel.org>,
yang.jie@linux.intel.com, linux-kernel@vger.kernel.org,
Eric Dumazet <edumazet@google.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>
Subject: Re: [PATCH] x86/aperfmperf: Make stale CPU frequency response within limits.
Date: Wed, 26 Jul 2023 16:43:26 +0200 [thread overview]
Message-ID: <CAJZ5v0jiQ-JFsFAFQFTZVGe-NobaRp7oo95R=Dju9b54n6iKEw@mail.gmail.com> (raw)
In-Reply-To: <CAAYoRsUu-5u73cSASua133EE3+zTRbTgq-kEn2L52e4=n6X46g@mail.gmail.com>
Hi Doug,
On Tue, Jul 25, 2023 at 9:12 PM Doug Smythies <dsmythies@telus.net> wrote:
>
> Hi Rafael,
>
> On Tue, Jul 25, 2023 at 11:31 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > On Tue, Jul 25, 2023 at 2:14 AM Doug Smythies <dsmythies@telus.net> wrote:
> > >
> > > Currently, when the CPU frequency is stale the nominal clock frequency
> > > is returned by calls to arch_freq_get_on_cpu(). Some users are
> > > confused by the high reported frequency when their system is idle
> > > and/or it is above a reduced maximum they set.
> > >
> > > This patch will return the policy minimum as the stale frequency reply
> > > from arch_freq_get_on_cpu().
> > >
> > > Reported-by: Yang Jie <yang.jie@linux.intel.com>
> > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=217597
> > > Signed-off-by: Doug Smythies <dsmythies@telus.net>
> > > ---
> > > arch/x86/kernel/cpu/aperfmperf.c | 13 +++++--------
> > > drivers/cpufreq/cpufreq.c | 18 ++++++++++++++++++
> > > include/linux/cpufreq.h | 5 +++++
> > > 3 files changed, 28 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/arch/x86/kernel/cpu/aperfmperf.c b/arch/x86/kernel/cpu/aperfmperf.c
> > > index fdbb5f07448f..44cc96864d94 100644
> > > --- a/arch/x86/kernel/cpu/aperfmperf.c
> > > +++ b/arch/x86/kernel/cpu/aperfmperf.c
> > > @@ -418,9 +418,10 @@ unsigned int arch_freq_get_on_cpu(int cpu)
> > > unsigned long last;
> > > u64 acnt, mcnt;
> > >
> > > - if (!cpu_feature_enabled(X86_FEATURE_APERFMPERF))
> > > - goto fallback;
> > > -
> > > + if (!cpu_feature_enabled(X86_FEATURE_APERFMPERF)){
> > > + freq = cpufreq_quick_get(cpu);
> > > + return freq ? freq : cpufreq_quick_get_min(cpu);
> > > + }
> > > do {
> > > seq = raw_read_seqcount_begin(&s->seq);
> > > last = s->last_update;
> > > @@ -433,13 +434,9 @@ unsigned int arch_freq_get_on_cpu(int cpu)
> > > * which covers idle and NOHZ full CPUs.
> > > */
> > > if (!mcnt || (jiffies - last) > MAX_SAMPLE_AGE)
> > > - goto fallback;
> > > + return cpufreq_quick_get_min(cpu);
> > >
> > > return div64_u64((cpu_khz * acnt), mcnt);
> > > -
> > > -fallback:
> > > - freq = cpufreq_quick_get(cpu);
> > > - return freq ? freq : cpu_khz;
> >
> > It looks to me like modifying cpufreq_quick_get) to return policy->min
> > if policy->cur is 0 would work in a similar way, wouldn't it?
>
> For the configuration of intel_cpufreq driver (intel_pstate in
> passive mode), schedutil governor, HWP enabled, for
> a stale frequency policy->cur is not 0 and will always
> be whatever the min value was when the driver was initialized,
> regardless of what has been set since.
So I would prefer to address this in the intel_pstate driver than to
work around it in the core.
> The patch I submitted deals with that situation also.
>
> A complete list of driver/governor/HWP stale frequency
> replies can be found on the bugzilla report at:
>
> https://bugzilla.kernel.org/attachment.cgi?id=304694
>
> There might be push back on some of the performance
> governor stale frequency replies. I could not figure out
> a performance governor dependant reply.
>
> Also there are other callers to cpufreq_quick_get
> and I was not sure I could mess with the function
> response for them. For example
> drivers/devfreq/tegra30-devfreq.c
> and drivers/thermal/cpufreq_cooling.c
> and drivers/powercap/dtpm_cpu.c
IIUC, all of the above rely on policy->cur being nonzero.
There are other users doing questionable things when
cpufreq_quick_get() returns 0 that I think would be better off if the
min is returned instead.
next prev parent reply other threads:[~2023-07-26 14:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-25 0:14 [PATCH] x86/aperfmperf: Make stale CPU frequency response within limits Doug Smythies
2023-07-25 18:31 ` Rafael J. Wysocki
2023-07-25 19:11 ` Doug Smythies
2023-07-26 14:43 ` Rafael J. Wysocki [this message]
2023-08-08 16:22 ` Doug Smythies
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='CAJZ5v0jiQ-JFsFAFQFTZVGe-NobaRp7oo95R=Dju9b54n6iKEw@mail.gmail.com' \
--to=rafael@kernel.org \
--cc=dsmythies@telus.net \
--cc=edumazet@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=tglx@linutronix.de \
--cc=viresh.kumar@linaro.org \
--cc=x86@kernel.org \
--cc=yang.jie@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).