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 18:46:35 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Doug Smythies <dsmythies@...us.net>
Cc:     Viresh Kumar <viresh.kumar@...aro.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Linux Kernel Mailing List <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 Thu, Aug 8, 2019 at 6:25 PM Doug Smythies <dsmythies@...us.net> wrote:
>
> On 2019.08.07 00:06 Viresh Kumar wrote:
>
> Thanks for your work on this.
>
> > Intel pstate driver exposes min_perf_pct and max_perf_pct sysfs files,
> > which can be used to force a limit on the min/max P state of the driver.
> > Though these files eventually control the min/max frequencies that the
> > CPUs will run at, they don't make a change to policy->min/max values.
> >
> > When the values of these files are changed (in passive mode of the
> > driver), it leads to calling ->limits() callback of the cpufreq
> > governors, like schedutil. On a call to it the governors shall
> > forcefully update the frequency to come within the limits. Since the
> > limits, i.e.  policy->min/max, aren't updated by the driver, the
> > governors fails to get the target freq within limit and sometimes aborts
> > the update believing that the frequency is already set to the target
> > value.
> >
> > This patch implements the QoS supported frequency constraints to update
> > policy->min/max values whenever min_perf_pct or max_perf_pct files are
> > updated. This is only done for the passive mode as of now, as the driver
> > is already working fine in active mode.
> >
> > Fixes: ecd288429126 ("cpufreq: schedutil: Don't set next_freq to UINT_MAX")
> > Reported-by: Doug Smythies <dsmythies@...us.net>
> > Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
>
> Tested by: Doug Smythies <dsmythies@...us.net>
> Thermald seems to now be working O.K. for all the governors.
>
> 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"?

For the min freq limit, the max of (scaling_min_freq, re-scaled
min_perf_pct) should be used.

For the max freq limit, the min of (scaling_max_freq, re-scaled
max_perf_pct) should be used.

Overall, the setting that "wins" is the one that causes the set of
available frequencies to be narrower.