Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1446440 > unrolled thread

[PATCH] intel_pstate: Update cpu_frequency tracepoint every time

Started by"Rafael J. Wysocki" <rjw@rjwysocki.net>
First post2016-07-19 15:10 +0200
Last post2016-07-23 14:40 +0200
Articles 4 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] intel_pstate: Update cpu_frequency tracepoint every time "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-07-19 15:10 +0200
    Re: [PATCH] intel_pstate: Update cpu_frequency tracepoint every time Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> - 2016-07-20 00:40 +0200
      RE: [PATCH] intel_pstate: Update cpu_frequency tracepoint every time "Doug Smythies" <dsmythies@telus.net> - 2016-07-20 05:20 +0200
        Re: [PATCH] intel_pstate: Update cpu_frequency tracepoint every time "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-07-23 14:40 +0200

#1446440 — [PATCH] intel_pstate: Update cpu_frequency tracepoint every time

From"Rafael J. Wysocki" <rjw@rjwysocki.net>
Date2016-07-19 15:10 +0200
Subject[PATCH] intel_pstate: Update cpu_frequency tracepoint every time
Message-ID<rWCWC-4qE-29@gated-at.bofh.it>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Currently, intel_pstate only updates the cpu_frequency tracepoint
if the new P-state to set is different from the current one, but
that causes powertop to report 100% idle on an 100% loaded system
sometimes.

Prevent that from happening by updating the cpu_frequency tracepoint
every time intel_pstate_update_pstate() is called.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/cpufreq/intel_pstate.c |   12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

Index: linux-pm/drivers/cpufreq/intel_pstate.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -1134,17 +1134,12 @@ static void intel_pstate_get_min_max(str
 	*min = clamp_t(int, min_perf, cpu->pstate.min_pstate, max_perf);
 }
 
-static inline void intel_pstate_record_pstate(struct cpudata *cpu, int pstate)
-{
-	trace_cpu_frequency(pstate * cpu->pstate.scaling, cpu->cpu);
-	cpu->pstate.current_pstate = pstate;
-}
-
 static void intel_pstate_set_min_pstate(struct cpudata *cpu)
 {
 	int pstate = cpu->pstate.min_pstate;
 
-	intel_pstate_record_pstate(cpu, pstate);
+	trace_cpu_frequency(pstate * cpu->pstate.scaling, cpu->cpu);
+	cpu->pstate.current_pstate = pstate;
 	/*
 	 * Generally, there is no guarantee that this code will always run on
 	 * the CPU being updated, so force the register update to run on the
@@ -1304,10 +1299,11 @@ static inline void intel_pstate_update_p
 
 	intel_pstate_get_min_max(cpu, &min_perf, &max_perf);
 	pstate = clamp_t(int, pstate, min_perf, max_perf);
+	trace_cpu_frequency(pstate * cpu->pstate.scaling, cpu->cpu);
 	if (pstate == cpu->pstate.current_pstate)
 		return;
 
-	intel_pstate_record_pstate(cpu, pstate);
+	cpu->pstate.current_pstate = pstate;
 	wrmsrl(MSR_IA32_PERF_CTL, pstate_funcs.get_val(cpu, pstate));
 }
 

[toc] | [next] | [standalone]


#1446757

FromSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date2016-07-20 00:40 +0200
Message-ID<rWLQd-1rn-5@gated-at.bofh.it>
In reply to#1446440
On Tue, 2016-07-19 at 15:10 +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> Currently, intel_pstate only updates the cpu_frequency tracepoint
> if the new P-state to set is different from the current one, but
> that causes powertop to report 100% idle on an 100% loaded system
> sometimes.
> 
> Prevent that from happening by updating the cpu_frequency tracepoint
> every time intel_pstate_update_pstate() is called.
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>-

> --
>  drivers/cpufreq/intel_pstate.c |   12 ++++--------
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/intel_pstate.c
> ===================================================================
> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
> +++ linux-pm/drivers/cpufreq/intel_pstate.c
> @@ -1134,17 +1134,12 @@ static void intel_pstate_get_min_max(str
>  	*min = clamp_t(int, min_perf, cpu->pstate.min_pstate,
> max_perf);
>  }
>  
> -static inline void intel_pstate_record_pstate(struct cpudata *cpu,
> int pstate)
> -{
> -	trace_cpu_frequency(pstate * cpu->pstate.scaling, cpu->cpu);
> -	cpu->pstate.current_pstate = pstate;
> -}
> -
>  static void intel_pstate_set_min_pstate(struct cpudata *cpu)
>  {
>  	int pstate = cpu->pstate.min_pstate;
>  
> -	intel_pstate_record_pstate(cpu, pstate);
> +	trace_cpu_frequency(pstate * cpu->pstate.scaling, cpu->cpu);
> +	cpu->pstate.current_pstate = pstate;
>  	/*
>  	 * Generally, there is no guarantee that this code will
> always run on
>  	 * the CPU being updated, so force the register update to
> run on the
> @@ -1304,10 +1299,11 @@ static inline void intel_pstate_update_p
>  
>  	intel_pstate_get_min_max(cpu, &min_perf, &max_perf);
>  	pstate = clamp_t(int, pstate, min_perf, max_perf);
> +	trace_cpu_frequency(pstate * cpu->pstate.scaling, cpu->cpu);
>  	if (pstate == cpu->pstate.current_pstate)
>  		return;
>  
> -	intel_pstate_record_pstate(cpu, pstate);
> +	cpu->pstate.current_pstate = pstate;
>  	wrmsrl(MSR_IA32_PERF_CTL, pstate_funcs.get_val(cpu,
> pstate));
>  }
>  
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]


#1446922

From"Doug Smythies" <dsmythies@telus.net>
Date2016-07-20 05:20 +0200
Message-ID<rWQdb-4mO-9@gated-at.bofh.it>
In reply to#1446757
On 2016.07.19 15:10 Srinivas Pandruvada wrote:
> On Tue, 2016-07-19 at 15:10 +0200, Rafael J. Wysocki wrote:
>> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> 
>> Currently, intel_pstate only updates the cpu_frequency tracepoint
>> if the new P-state to set is different from the current one, but
>> that causes powertop to report 100% idle on an 100% loaded system
>> sometimes.
>> 
>> Prevent that from happening by updating the cpu_frequency tracepoint
>> every time intel_pstate_update_pstate() is called.
>> 
>> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>-

Shouldn't this patch refer to:

commit fdfdb2b1301670a69195ba1e5666df4a7f02eb46
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Fri Mar 18 23:20:02 2016 +0100

    intel_pstate: Do not call wrmsrl_on_cpu() with disabled interrupts

which is the patch that introduced the regression?

... Doug

[toc] | [prev] | [next] | [standalone]


#1448943

From"Rafael J. Wysocki" <rjw@rjwysocki.net>
Date2016-07-23 14:40 +0200
Message-ID<rY4nM-2MG-29@gated-at.bofh.it>
In reply to#1446922
On Tuesday, July 19, 2016 08:14:53 PM Doug Smythies wrote:
> On 2016.07.19 15:10 Srinivas Pandruvada wrote:
> > On Tue, 2016-07-19 at 15:10 +0200, Rafael J. Wysocki wrote:
> >> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >> 
> >> Currently, intel_pstate only updates the cpu_frequency tracepoint
> >> if the new P-state to set is different from the current one, but
> >> that causes powertop to report 100% idle on an 100% loaded system
> >> sometimes.
> >> 
> >> Prevent that from happening by updating the cpu_frequency tracepoint
> >> every time intel_pstate_update_pstate() is called.
> >> 
> >> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>-
> 
> Shouldn't this patch refer to:
> 
> commit fdfdb2b1301670a69195ba1e5666df4a7f02eb46
> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Date:   Fri Mar 18 23:20:02 2016 +0100
> 
>     intel_pstate: Do not call wrmsrl_on_cpu() with disabled interrupts
> 
> which is the patch that introduced the regression?

The logic changed by the $subject patch was there before the above commit,
so I don't think the issue at hand really is a regression introduced by it

Thanks,
Rafael

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web