linux-kernel - Re: [PATCH v2 2/3] cpufreq: intel_pstate: Do not reinit performance limits in ->setpolicy

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 2 Mar 2017 18:18:44 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:     Linux PM <linux-pm@...r.kernel.org>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/3] cpufreq: intel_pstate: Do not reinit performance
 limits in ->setpolicy

On Wed, Mar 1, 2017 at 12:09 AM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>
> If the current P-state selection algorithm is set to "performance"
> in intel_pstate_set_policy(), the limits may be initialized from
> scratch, but only if no_turbo is not set and the maximum frequency
> allowed for the given CPU (i.e. the policy object representing it)
> is at least equal to the max frequency supported by the CPU.  In all
> of the other cases, the limits will not be updated.
>
> For example, the following can happen:
>
>  # cat intel_pstate/status
>  active
>  # echo performance > cpufreq/policy0/scaling_governor
>  # cat intel_pstate/min_perf_pct
>  100
>  # echo 94 > intel_pstate/min_perf_pct
>  # cat intel_pstate/min_perf_pct
>  100
>  # cat cpufreq/policy0/scaling_max_freq
>  3100000
>  echo 3000000 > cpufreq/policy0/scaling_max_freq
>  # cat intel_pstate/min_perf_pct
>  94
>  # echo 95 > intel_pstate/min_perf_pct
>  # cat intel_pstate/min_perf_pct
>  95
>
> That is confusing for two reasons.  First, the initial attempt to
> change min_perf_pct to 94 seems to have no effect, even though
> setting the global limits should always work.  Second, after
> changing scaling_max_freq for policy0 the global min_perf_pct
> attribute shows 94, even though it should have not been affected
> by that operation in principle.
>
> Moreover, the final attempt to change min_perf_pct to 95 worked
> as expected, because scaling_max_freq for the only policy with
> scaling_governor equal to "performance" was different from the
> maximum at that time.
>
> To make all that confusion go away, modify intel_pstate_set_policy()
> so that it doesn't reinitialize the limits at all.
>
> At the same time, change intel_pstate_set_performance_limits() to
> set min_sysfs_pct to 100 in the "performance" limits set so that
> switching the P-state selection algorithm to "performance" causes
> intel_pstate/min_perf_pct in sysfs to go to 100 (or whatever value
> min_sysfs_pct in the "performance" limits is set to later).
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> ---
>
> -> v2: No changes
>
> ---
>  drivers/cpufreq/intel_pstate.c |   10 +++-------
>  1 file changed, 3 insertions(+), 7 deletions(-)
>
> Index: linux-pm/drivers/cpufreq/intel_pstate.c
> ===================================================================
> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
> +++ linux-pm/drivers/cpufreq/intel_pstate.c
> @@ -382,6 +382,7 @@ static void intel_pstate_set_performance
>         intel_pstate_init_limits(limits);
>         limits->min_perf_pct = 100;
>         limits->min_perf = int_ext_tofp(1);
> +       limits->min_sysfs_pct = 100;

This change breaks the per-CPU limits, so the patch is not correct.

Withdrawing.

Thanks,
Rafael