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]

Date:   Thu, 8 Aug 2019 23:35:25 -0700
From:   "Doug Smythies" <dsmythies@...us.net>
To:     "'Viresh Kumar'" <viresh.kumar@...aro.org>
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 2019.08.08 19:16 Viresh Kumar wrote:
> On 08-08-19, 09:25, Doug Smythies wrote:
>> On 2019.08.07 00:06 Viresh Kumar wrote:
>> Tested by: Doug Smythies <dsmythies@...us.net>
>> Thermald seems to now be working O.K. for all the governors.
>
> Thanks for testing Doug.
> 
>> I do note that if one sets
>> /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq
>> It seems to override subsequent attempts via
>> /sys/devices/system/cpu/intel_pstate/max_perf_pct.
>> Myself, I find this confusing.
>> 
>> So the question becomes which one is the "master"?
>
> No one is master, cpufreq takes all the requests for frequency
> constraints and tries to set the value based on aggregation of all. So
> for max frequency, the lowest value wins and is shown up in sysfs.
>
> So, everything looks okay to me.

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.

... Doug