| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAAYoRsUu-5u73cSASua133EE3+zTRbTgq-kEn2L52e4=n6X46g@mail.gmail.com>
Date: Tue, 25 Jul 2023 12:11:47 -0700
From: Doug Smythies <dsmythies@...us.net>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, linux-pm@...r.kernel.org,
"the arch/x86 maintainers" <x86@...nel.org>,
yang.jie@...ux.intel.com, linux-kernel@...r.kernel.org,
Eric Dumazet <edumazet@...gle.com>,
"Paul E. McKenney" <paulmck@...nel.org>,
Viresh Kumar <viresh.kumar@...aro.org>,
Doug Smythies <dsmythies@...us.net>
Subject: Re: [PATCH] x86/aperfmperf: Make stale CPU frequency response within limits.
Hi Rafael,
On Tue, Jul 25, 2023 at 11:31 AM Rafael J. Wysocki <rafael@...nel.org> wrote:
> On Tue, Jul 25, 2023 at 2:14 AM Doug Smythies <dsmythies@...us.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@...ux.intel.com>
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=217597
> > Signed-off-by: Doug Smythies <dsmythies@...us.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.
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
>
> > }
> >
> > static int __init bp_init_aperfmperf(void)
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 50bbc969ffe5..a0b24f61a5b0 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -1796,6 +1796,24 @@ unsigned int cpufreq_quick_get_max(unsigned int cpu)
> > }
> > EXPORT_SYMBOL(cpufreq_quick_get_max);
> >
> > +/**
> > + * cpufreq_quick_get_min - return the min frequency for a given CPU
> > + * @cpu: CPU number
> > + */
> > +unsigned int cpufreq_quick_get_min(unsigned int cpu)
> > +{
> > + struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
> > + unsigned int ret_freq = 0;
> > +
> > + if (policy) {
> > + ret_freq = policy->min;
> > + cpufreq_cpu_put(policy);
> > + }
> > +
> > + return ret_freq;
> > +}
> > +EXPORT_SYMBOL(cpufreq_quick_get_min);
> > +
> > /**
> > * cpufreq_get_hw_max_freq - get the max hardware frequency of the CPU
> > * @cpu: CPU number
> > diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> > index 172ff51c1b2a..c74dcb5f9263 100644
> > --- a/include/linux/cpufreq.h
> > +++ b/include/linux/cpufreq.h
> > @@ -220,6 +220,7 @@ static inline bool policy_is_shared(struct cpufreq_policy *policy)
> > unsigned int cpufreq_get(unsigned int cpu);
> > unsigned int cpufreq_quick_get(unsigned int cpu);
> > unsigned int cpufreq_quick_get_max(unsigned int cpu);
> > +unsigned int cpufreq_quick_get_min(unsigned int cpu);
> > unsigned int cpufreq_get_hw_max_freq(unsigned int cpu);
> > void disable_cpufreq(void);
> >
> > @@ -250,6 +251,10 @@ static inline unsigned int cpufreq_quick_get_max(unsigned int cpu)
> > {
> > return 0;
> > }
> > +static inline unsigned int cpufreq_quick_get_min(unsigned int cpu)
> > +{
> > + return 0;
> > +}
> > static inline unsigned int cpufreq_get_hw_max_freq(unsigned int cpu)
> > {
> > return 0;
> > --
> > 2.25.1
> >
> >
Powered by blists - more mailing lists