Hi Thara,
On 11/15/21 1:50 PM, Thara Gopinath wrote:
cpuinfo.max_freq reflects the maximum supported frequency of cpus in a
cpufreq policy. When cpus support boost frequency and if boost is disabled
during boot up (which is the default), cpuinfo.max_freq does not reflect
boost frequency as the maximum supported frequency till boost is explicitly
enabled via sysfs interface later. This also means that policy reports two
different cpuinfo.max_freq before and after turning on boost. Fix this by
separating out setting of policy->max and cpuinfo.max_freq in
cpufreq_frequency_table_cpuinfo.
e.g. of the problem. Qualcomm sdm845 supports boost frequency for gold
cluster (cpus 4-7). After boot up (boost disabled),
1. cat /sys/devices/system/cpu/cpufreq/policy4/cpuinfo_max_freq 2649600
<- This is wrong because boost frequency is
2. echo 1 > /sys/devices/system/cpu/cpufreq/boost <- Enable boost cat
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_max_freq 2803200 <-
max freq reflects boost freq.
3. echo 0 > /sys/devices/system/cpu/cpufreq/boost <- Disable boost cat
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_max_freq 2803200 <-
Discrepancy with step 1 as in both cases boost is disabled.
Note that the other way to fix this is to set cpuinfo.max_freq in Soc
cpufreq driver during initialization. Fixing it in
cpufreq_frequency_table_cpuinfo seems more generic solution
Signed-off-by: Thara Gopinath <thara.gopinath@xxxxxxxxxx>
---
drivers/cpufreq/freq_table.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index 67e56cf638ef..6784f94124df 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -35,11 +35,15 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
struct cpufreq_frequency_table *pos;
unsigned int min_freq = ~0;
unsigned int max_freq = 0;
+ unsigned int cpuinfo_max_freq = 0;
unsigned int freq;
cpufreq_for_each_valid_entry(pos, table) {
freq = pos->frequency;
+ if (freq > cpuinfo_max_freq)
+ cpuinfo_max_freq = freq;
+
if (!cpufreq_boost_enabled()
&& (pos->flags & CPUFREQ_BOOST_FREQ))
continue;
@@ -57,8 +61,8 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
* If the driver has set its own cpuinfo.max_freq above max_freq, leave
* it as is.
*/
- if (policy->cpuinfo.max_freq < max_freq)
- policy->max = policy->cpuinfo.max_freq = max_freq;
+ if (policy->cpuinfo.max_freq < cpuinfo_max_freq)
+ policy->cpuinfo.max_freq = cpuinfo_max_freq;
if (policy->min == ~0)
return -EINVAL;
Something still isn't quite right...
The setup is that I have an rc.local of
#!/bin/sh
echo 1 > /sys/devices/system/cpu/cpufreq/boost
exit 0
After booting and logging in:
steev@limitless:~$ cat
/sys/devices/system/cpu/cpufreq/policy4/stats/time_in_state
825600 2499
<snip>
2649600 38
2745600 31
2841600 1473
2956800 0
After running a "cargo build --release" in an alacritty git checkout:
teev@limitless:~$ cat
/sys/devices/system/cpu/cpufreq/policy4/stats/time_in_state
825600 11220
<snip>
2649600 41
2745600 35
2841600 3065
2956800 0
however...
If I then
steev@limitless:~$ echo 0 | sudo tee /sys/devices/system/cpu/cpufreq/boost
[sudo] password for steev:
0
steev@limitless:~$ echo 1 | sudo tee /sys/devices/system/cpu/cpufreq/boost
1
and run the build again...
steev@limitless:~$ cat
/sys/devices/system/cpu/cpufreq/policy4/stats/time_in_state
825600 21386
<snip>
2649600 45
2745600 38
2841600 3326
2956800 4815
As a workaround, I attempted to jiggle it 1-0-1 in rc.local, however
that ends up giving
steev@limitless:~$ cat
/sys/devices/system/cpu/cpufreq/policy4/stats/time_in_state
825600 2902
<snip>
2649600 36
2745600 36
2841600 6050
2956800 13
And it doesn't go up, I even tried adding a sleep of 1 second between
the echo 1/0/1 lines and while 2956800 goes up to 28 (but never uses it)
it seems like, unless I do it manually once I've logged in, which I'm
assuming is a lot slower than waiting 1 second between them, it's not
quite giving us 2956800 "easily".
If the email wasn't clear, please let me know! I tried to explain as
best I could what I am seeing here.
-- steev
