linux-kernel - Re: [PATCH 1/2] cpufreq: intel_pstate: Clean up after performance governor changes

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] [day] [month] [year] [list]

Message-ID: <1498771188.7952.114.camel@linux.intel.com>
Date:   Thu, 29 Jun 2017 14:19:48 -0700
From:   Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
To:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux PM <linux-pm@...r.kernel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] cpufreq: intel_pstate: Clean up after performance
 governor changes

On Thu, 2017-06-29 at 01:47 +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> 
> After commit 82b4e03e01bc (intel_pstate: skip scheduler hook when in
> "performance" mode) get_target_pstate_use_performance() and
> get_target_pstate_use_cpu_load() are never called if scaling_governor
> is "performance", so drop the CPUFREQ_POLICY_PERFORMANCE checks from
> them as they will never trigger anyway.
> 
> Moreover, the documentation needs to be updated to reflect the change
> made by the above commit, so do that too.
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>

> ---
>  Documentation/admin-guide/pm/intel_pstate.rst |    6 ++----
>  drivers/cpufreq/intel_pstate.c                |    6 ------
>  2 files changed, 2 insertions(+), 10 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/intel_pstate.c
> ===================================================================
> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
> +++ linux-pm/drivers/cpufreq/intel_pstate.c
> @@ -1612,9 +1612,6 @@ static inline int32_t get_target_pstate_
>  	int32_t busy_frac, boost;
>  	int target, avg_pstate;
>  
> -	if (cpu->policy == CPUFREQ_POLICY_PERFORMANCE)
> -		return cpu->pstate.turbo_pstate;
> -
>  	busy_frac = div_fp(sample->mperf, sample->tsc);
>  
>  	boost = cpu->iowait_boost;
> @@ -1651,9 +1648,6 @@ static inline int32_t get_target_pstate_
>  	int32_t perf_scaled, max_pstate, current_pstate,
> sample_ratio;
>  	u64 duration_ns;
>  
> -	if (cpu->policy == CPUFREQ_POLICY_PERFORMANCE)
> -		return cpu->pstate.turbo_pstate;
> -
>  	/*
>  	 * perf_scaled is the ratio of the average P-state during
> the last
>  	 * sampling period to the P-state requested last time (in
> percent).
> Index: linux-pm/Documentation/admin-guide/pm/intel_pstate.rst
> ===================================================================
> --- linux-pm.orig/Documentation/admin-guide/pm/intel_pstate.rst
> +++ linux-pm/Documentation/admin-guide/pm/intel_pstate.rst
> @@ -157,10 +157,8 @@ Without HWP, this P-state selection algo
>  the processor model and platform configuration.
>  
>  It selects the maximum P-state it is allowed to use, subject to
> limits set via
> -``sysfs``, every time the P-state selection computations are carried
> out by the
> -driver's utilization update callback for the given CPU (that does
> not happen
> -more often than every 10 ms), but the hardware configuration will
> not be changed
> -if the new P-state is the same as the current one.
> +``sysfs``, every time the driver configuration for the given CPU is
> updated
> +(e.g. via ``sysfs``).
>  
>  This is the default P-state selection algorithm if the
>  :c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel
> configuration option
>