Re: [PATCH] cpufreq: freq_table: Initialize cpuinfo.max_freq to correct max frequency.

[Steev Klimaszewski <steev@kali.org>]

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@linaro.org>
> ---
>   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