[PATCH 0/2] cpufreq: intel_pstate: Cleanups after recent changes

[PATCH 0/2] cpufreq: intel_pstate: Cleanups after recent changes

[Rafael J. Wysocki]

Hi,

The following two patches clean up intel_pstate and cpufreq documentation after
changes currently queued up in linux-next.

Thanks,
Rafael

[PATCH 1/2] cpufreq: intel_pstate: Clean up after performance governor changes

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.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@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

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

[Srinivas Pandruvada]

On Thu, 2017-06-29 at 01:47 +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.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@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.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
> 

[PATCH 2/2] cpufreq: Update scaling_cur_freq documentation

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit f8475cef9008 "x86: use common aperfmperf_khz_on_cpu() to
calculate KHz using APERF/MPERF" modified the way the scaling_cur_freq
cpufreq policy attribute in sysfs is handled on contemporary
Intel-based x86 systems, so update the documentation to reflect
that change.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 Documentation/admin-guide/pm/cpufreq.rst |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

Index: linux-pm/Documentation/admin-guide/pm/cpufreq.rst
===================================================================
--- linux-pm.orig/Documentation/admin-guide/pm/cpufreq.rst
+++ linux-pm/Documentation/admin-guide/pm/cpufreq.rst
@@ -269,16 +269,16 @@ are the following:
 ``scaling_cur_freq``
 	Current frequency of all of the CPUs belonging to this policy (in kHz).
 
-	For the majority of scaling drivers, this is the frequency of the last
-	P-state requested by the driver from the hardware using the scaling
+	In the majority of cases, this is the frequency of the last P-state
+	requested by the scaling driver from the hardware using the scaling
 	interface provided by it, which may or may not reflect the frequency
 	the CPU is actually running at (due to hardware design and other
 	limitations).
 
-	Some scaling drivers (e.g. |intel_pstate|) attempt to provide
-	information more precisely reflecting the current CPU frequency through
-	this attribute, but that still may not be the exact current CPU
-	frequency as seen by the hardware at the moment.
+	Some architectures (e.g. ``x86``) may attempt to provide information
+	more precisely reflecting the current CPU frequency through this
+	attribute, but that still may not be the exact current CPU frequency as
+	seen by the hardware at the moment.
 
 ``scaling_driver``
 	The scaling driver currently in use.