From: "Doug Smythies" <dsmythies@telus.net>
To: "'Thomas Gleixner'" <tglx@linutronix.de>,
"'Rafael J. Wysocki'" <rafael@kernel.org>
Cc: "'the arch/x86 maintainers'" <x86@kernel.org>,
"'Rafael J. Wysocki'" <rafael@kernel.org>,
"'Linux PM'" <linux-pm@vger.kernel.org>,
"'Eric Dumazet'" <edumazet@google.com>,
"'Paul E. McKenney'" <paulmck@kernel.org>,
"'LKML'" <linux-kernel@vger.kernel.org>,
"Doug Smythies" <dsmythies@telus.net>
Subject: RE: [patch 00/10] x86/cpu: Consolidate APERF/MPERF code
Date: Wed, 20 Apr 2022 15:08:56 -0700 [thread overview]
Message-ID: <005501d85503$3b00ca40$b1025ec0$@telus.net> (raw)
In-Reply-To: <87bkwwvkwa.ffs@tglx>
Hi Thomas, Rafael,
Thank you for your replies.
On 2022.04.19 14:11 Thomas Gleixner wrote:
> On Tue, Apr 19 2022 at 20:49, Rafael J. Wysocki wrote:
>> On Tue, Apr 19, 2022 at 7:32 PM Doug Smythies <dsmythies@telus.net> wrote:
>>> For intel_pstate (active), both HWP enabled or disabled, the behaviour
>>> of scaling_cur_freq is inconsistent with prior to this patch set and other
>>> scaling driver governor combinations.
>>>
>>> Note there is no issue with " grep MHz /proc/cpuinfo" for any
>>> combination.
>>>
>>> Examples:
>>>
>>> No-HWP:
>>>
>>> active/powersave:
>>> doug@s19:~/freq-scalers/trace$ grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
>>> /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:2300418
>>> /sys/devices/system/cpu/cpu10/cpufreq/scaling_cur_freq:0
>>> /sys/devices/system/cpu/cpu11/cpufreq/scaling_cur_freq:0
>>> /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq:0
>>> /sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_freq:0
>>> /sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq:0
>>> /sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq:0
>>> /sys/devices/system/cpu/cpu5/cpufreq/scaling_cur_freq:0
>>> /sys/devices/system/cpu/cpu6/cpufreq/scaling_cur_freq:0
>>> /sys/devices/system/cpu/cpu7/cpufreq/scaling_cur_freq:2300006
>>> /sys/devices/system/cpu/cpu8/cpufreq/scaling_cur_freq:2300005
>>> /sys/devices/system/cpu/cpu9/cpufreq/scaling_cur_freq:0
>>
>> That's because after the changes in this series scaling_cur_freq
>> returns 0 if the given CPU is idle.
>
> Which is sensible IMO as there is really no point in waking an idle CPU
> just to read those MSRs, then wait 20ms wake it up again to read those
> MSRs again.
I totally agree.
It is the inconsistency for what is displayed as a function of driver/governor
that is my concern.
>
>> I guess it could return the last known result, but that wouldn't be
>> more meaningful.
>
> Right.
How about something like this, which I realize might break something else,
but just to demonstrate:
doug@s19:~/kernel/linux$ git diff
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 80f535cc8a75..a161e75794cd 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -710,7 +710,7 @@ static ssize_t show_scaling_cur_freq(struct cpufreq_policy *policy, char *buf)
else if (cpufreq_driver->setpolicy && cpufreq_driver->get)
ret = sprintf(buf, "%u\n", cpufreq_driver->get(policy->cpu));
else
- ret = sprintf(buf, "%u\n", policy->cur);
+ ret = sprintf(buf, "%u\n", freq);
return ret;
}
Note: I left the other 0 return condition, because I do not know what uses it.
Which gives:
acpi-cpufreq/schedutil
doug@s19:~/kernel/linux$ grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu10/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu11/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu5/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu6/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu7/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu8/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu9/cpufreq/scaling_cur_freq:4100723
intel_pstate/powersave (no-HWP)
doug@s19:~/kernel/linux$ grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu10/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu11/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu5/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu6/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu7/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu8/cpufreq/scaling_cur_freq:800295
/sys/devices/system/cpu/cpu9/cpufreq/scaling_cur_freq:800015
intel_cpufreq/schedutil (no-HWP)
doug@s19:~/kernel/linux$ grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu10/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu11/cpufreq/scaling_cur_freq:1971265
/sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu5/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu6/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu7/cpufreq/scaling_cur_freq:0
/sys/devices/system/cpu/cpu8/cpufreq/scaling_cur_freq:2785446
/sys/devices/system/cpu/cpu9/cpufreq/scaling_cur_freq:0
Which I suggest is more consistent.
Note: because it was deleted from this thread,
and just for reference, I'll repost the previous
intel_cpufreq/schedutil (no-HWP) output:
doug@s19:~$ grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:800000
/sys/devices/system/cpu/cpu10/cpufreq/scaling_cur_freq:1067573
/sys/devices/system/cpu/cpu11/cpufreq/scaling_cur_freq:800000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq:800000
/sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_freq:800000
/sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq:800011
/sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq:800000
/sys/devices/system/cpu/cpu5/cpufreq/scaling_cur_freq:800109
/sys/devices/system/cpu/cpu6/cpufreq/scaling_cur_freq:800000
/sys/devices/system/cpu/cpu7/cpufreq/scaling_cur_freq:800000
/sys/devices/system/cpu/cpu8/cpufreq/scaling_cur_freq:800000
/sys/devices/system/cpu/cpu9/cpufreq/scaling_cur_freq:800000
... Doug
next prev parent reply other threads:[~2022-04-20 22:09 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-15 19:19 [patch 00/10] x86/cpu: Consolidate APERF/MPERF code Thomas Gleixner
2022-04-15 19:19 ` [patch 01/10] x86/aperfmperf: Dont wake idle CPUs in arch_freq_get_on_cpu() Thomas Gleixner
2022-04-19 15:34 ` Rafael J. Wysocki
2022-04-27 13:56 ` [tip: x86/cleanups] " tip-bot2 for Thomas Gleixner
2022-04-15 19:19 ` [patch 02/10] x86/smp: Move APERF/MPERF code where it belongs Thomas Gleixner
2022-04-19 15:40 ` Rafael J. Wysocki
2022-04-27 13:56 ` [tip: x86/cleanups] " tip-bot2 for Thomas Gleixner
2022-04-15 19:19 ` [patch 03/10] x86/aperfmperf: Separate AP/BP frequency invariance init Thomas Gleixner
2022-04-19 16:04 ` Rafael J. Wysocki
2022-04-27 13:56 ` [tip: x86/cleanups] " tip-bot2 for Thomas Gleixner
2022-04-15 19:19 ` [patch 04/10] x86/aperfmperf: Untangle Intel and AMD " Thomas Gleixner
2022-04-19 16:12 ` Rafael J. Wysocki
2022-04-27 13:56 ` [tip: x86/cleanups] " tip-bot2 for Thomas Gleixner
2022-04-27 18:27 ` tip-bot2 for Thomas Gleixner
2022-04-15 19:19 ` [patch 05/10] x86/aperfmperf: Put frequency invariance aperf/mperf data into a struct Thomas Gleixner
2022-04-19 16:15 ` Rafael J. Wysocki
2022-04-27 13:56 ` [tip: x86/cleanups] " tip-bot2 for Thomas Gleixner
2022-04-27 18:27 ` tip-bot2 for Thomas Gleixner
2022-04-15 19:19 ` [patch 06/10] x86/aperfmperf: Restructure arch_scale_freq_tick() Thomas Gleixner
2022-04-19 16:20 ` Rafael J. Wysocki
2022-04-27 13:56 ` [tip: x86/cleanups] " tip-bot2 for Thomas Gleixner
2022-04-27 18:27 ` tip-bot2 for Thomas Gleixner
2022-04-15 19:19 ` [patch 07/10] x86/aperfmperf: Make parts of the frequency invariance code unconditional Thomas Gleixner
2022-04-19 16:27 ` Rafael J. Wysocki
2022-04-27 13:56 ` [tip: x86/cleanups] " tip-bot2 for Thomas Gleixner
2022-04-27 18:27 ` tip-bot2 for Thomas Gleixner
2022-04-15 19:20 ` [patch 08/10] x86/aperfmperf: Store aperf/mperf data for cpu frequency reads Thomas Gleixner
2022-04-19 16:30 ` Rafael J. Wysocki
2022-04-27 13:56 ` [tip: x86/cleanups] " tip-bot2 for Thomas Gleixner
2022-04-27 18:27 ` tip-bot2 for Thomas Gleixner
2022-04-15 19:20 ` [patch 09/10] x86/aperfmperf: Replace aperfmperf_get_khz() Thomas Gleixner
2022-04-19 16:35 ` Rafael J. Wysocki
2022-04-27 13:56 ` [tip: x86/cleanups] " tip-bot2 for Thomas Gleixner
2022-04-27 18:27 ` tip-bot2 for Thomas Gleixner
2022-04-15 19:20 ` [patch 10/10] x86/aperfmperf: Replace arch_freq_get_on_cpu() Thomas Gleixner
2022-04-19 16:37 ` Rafael J. Wysocki
2022-04-27 13:56 ` [tip: x86/cleanups] " tip-bot2 for Thomas Gleixner
2022-04-27 18:27 ` tip-bot2 for Thomas Gleixner
2022-04-19 15:51 ` [patch 00/10] x86/cpu: Consolidate APERF/MPERF code Eric Dumazet
2022-04-19 20:39 ` Thomas Gleixner
2022-04-19 21:20 ` Eric Dumazet
2022-04-19 16:41 ` Peter Zijlstra
2022-04-19 17:32 ` Doug Smythies
2022-04-19 18:49 ` Rafael J. Wysocki
2022-04-19 21:11 ` Thomas Gleixner
2022-04-20 22:08 ` Doug Smythies [this message]
2022-04-25 15:45 ` Thomas Gleixner
2022-04-25 23:20 ` Doug Smythies
2022-04-27 13:56 ` [tip: x86/cleanups] x86/aperfmperf: Integrate the fallback code from show_cpuinfo() tip-bot2 for Thomas Gleixner
2022-04-27 18:27 ` tip-bot2 for Thomas Gleixner
2022-04-19 21:56 ` [patch 00/10] x86/cpu: Consolidate APERF/MPERF code Paul E. McKenney
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='005501d85503$3b00ca40$b1025ec0$@telus.net' \
--to=dsmythies@telus.net \
--cc=edumazet@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=rafael@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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.