linux-kernel - Re: [PATCH V4 2/2] cpufreq: intel_pstate: Implement QoS supported freq constraints

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190809065106.vpktdp44qohdt3jk@vireshk-i7>
Date:   Fri, 9 Aug 2019 12:21:06 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Doug Smythies <dsmythies@...us.net>
Cc:     linux-pm@...r.kernel.org,
        'Vincent Guittot' <vincent.guittot@...aro.org>,
        linux-kernel@...r.kernel.org, 'Rafael Wysocki' <rjw@...ysocki.net>,
        'Srinivas Pandruvada' <srinivas.pandruvada@...ux.intel.com>,
        'Len Brown' <lenb@...nel.org>
Subject: Re: [PATCH V4 2/2] cpufreq: intel_pstate: Implement QoS supported
 freq constraints

On 08-08-19, 23:35, Doug Smythies wrote:
> O.K. While I understand the explanations, I still struggle with
> this scenario:
>  
> doug@s15:~/temp$ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
> 50    <<< Note: 50% = 1.9 GHz in my system)
> doug@s15:~/temp$ grep . /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq
> /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:1900000
> /sys/devices/system/cpu/cpufreq/policy1/scaling_max_freq:1900000
> /sys/devices/system/cpu/cpufreq/policy2/scaling_max_freq:1900000
> /sys/devices/system/cpu/cpufreq/policy3/scaling_max_freq:1900000
> /sys/devices/system/cpu/cpufreq/policy4/scaling_max_freq:1900000
> /sys/devices/system/cpu/cpufreq/policy5/scaling_max_freq:1900000
> /sys/devices/system/cpu/cpufreq/policy6/scaling_max_freq:1900000
> /sys/devices/system/cpu/cpufreq/policy7/scaling_max_freq:1900000
> 
> At this point I am not certain what I'll get if I try to
> set max_perf_pct to 100%, nor do I know how to find out
> with a user command.
> 
> So, I'll try it:
> 
> doug@s15:~/temp$ echo 100 | sudo tee /sys/devices/system/cpu/intel_pstate/max_perf_pct
> 100
> doug@s15:~/temp$ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
> 100  <<< Note: 100% = 3.8 GHz in my system)
> doug@s15:~/temp$ grep . /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq
> /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:2200000
> /sys/devices/system/cpu/cpufreq/policy1/scaling_max_freq:2200000
> /sys/devices/system/cpu/cpufreq/policy2/scaling_max_freq:2200000
> /sys/devices/system/cpu/cpufreq/policy3/scaling_max_freq:2200000
> /sys/devices/system/cpu/cpufreq/policy4/scaling_max_freq:2200000
> /sys/devices/system/cpu/cpufreq/policy5/scaling_max_freq:2200000
> /sys/devices/system/cpu/cpufreq/policy6/scaling_max_freq:2200000
> /sys/devices/system/cpu/cpufreq/policy7/scaling_max_freq:2200000
> 
> I guess I had set it sometime earlier, forgot, and then didn't
> get 3.8 Ghz as I had expected via max_perf_pct.

Right, so the problem here (since ages) is that there is no file in
sysfs to show the value earlier set by the user to
scaling_max/min_freq. Rather when you try to read those files, cpufreq
core gives you the current value of policy->min/max, which can come
from so many factors, like userspace, thermal, max_perf_pct, etc.

You saw 2200000 here because you must have set that value to
scaling_max_freq earlier, else maybe thermal or other stuff
constrained that value for you.

Though the cpufreq core stores the value set by user and uses it to
recalculate policy->max using it. To get rid of your constraint, set
scaling_max_freq to the highest frequency and you will be good.

-- 
viresh