Messages in this thread | | | From | "Rafael J. Wysocki" <> | Date | Wed, 26 Jul 2023 16:43:26 +0200 | Subject | Re: [PATCH] x86/aperfmperf: Make stale CPU frequency response within limits. |
| |
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.
| |