* Re: Problem: Possible regression in intel_pstate on 3.12
[not found] <20131208172508.0cacabd0@tor.valhalla.alchemy.lu>
@ 2013-12-16 9:08 ` Viresh Kumar
2013-12-16 17:28 ` Dirk Brandewie
0 siblings, 1 reply; 3+ messages in thread
From: Viresh Kumar @ 2013-12-16 9:08 UTC (permalink / raw)
To: Joakim Hernberg, Dirk Brandewie
Cc: Linux Kernel Mailing List, Rafael J. Wysocki,
linux-pm@vger.kernel.org
Adding Dirk in cc..
On 8 December 2013 21:55, Joakim Hernberg <jbh@alchemy.lu> wrote:
> When I'm running KDE on linux 3.12 (archlinux) my intel i7-2600k seems
> to no longer reduce the cpu multiplier and thus runs hotter than under
> linux 3.11. i7z shows the cpu as being close to idle and using C0 to
> C6 states.
>
> On "Linux version 3.12.3-1-ARCH (tobias@T-POWA-LX) (gcc version 4.8.2
> (GCC) ) #1 SMP PREEMPT Wed Dec 4 21:45:42 CET 2013"
>
> Output of # cpupower frequency-list when booted to the command prompt:
>
> analyzing CPU 0:
> driver: intel_pstate
> CPUs which run at the same hardware frequency: 0
> CPUs which need to have their frequency coordinated by software: 0
> maximum transition latency: 0.97 ms.
> hardware limits: 1.60 GHz - 5.90 GHz
> available cpufreq governors: performance, powersave
> current policy: frequency should be within 1.60 GHz and 5.90 GHz.
> The governor "powersave" may decide which speed to use
> within this range.
> current CPU frequency is 1.69 GHz (asserted by call to hardware).
> boost state support:
> Supported: yes
> Active: yes
> 25500 MHz max turbo 4 active cores
> 25500 MHz max turbo 3 active cores
> 25500 MHz max turbo 2 active cores
> 25500 MHz max turbo 1 active cores
>
> When booted into KDE and system more or less idle:
>
> analyzing CPU 0:
> driver: intel_pstate
> CPUs which run at the same hardware frequency: 0
> CPUs which need to have their frequency coordinated by software: 0
> maximum transition latency: 0.97 ms.
> hardware limits: 1.60 GHz - 5.90 GHz
> available cpufreq governors: performance, powersave
> current policy: frequency should be within 1.60 GHz and 5.90 GHz.
> The governor "powersave" may decide which speed to use
> within this range.
> current CPU frequency is 4.30 GHz (asserted by call to hardware).
> boost state support:
> Supported: yes
> Active: yes
> 25500 MHz max turbo 4 active cores
> 25500 MHz max turbo 3 active cores
> 25500 MHz max turbo 2 active cores
> 25500 MHz max turbo 1 active cores
>
> Output of top while in KDE:
>
> top - 14:21:13 up 9 min, 16 users, load average: 0.48, 0.88, 0.59
> Tasks: 205 total, 1 running, 204 sleeping, 0 stopped, 0 zombie
> %Cpu(s): 1.2 us, 0.4 sy, 0.0 ni, 98.1 id, 0.3 wa, 0.0 hi, 0.0
> si, 0.0 st KiB Mem: 15366248 total, 2435540 used, 12930708 free,
> 71804 buffers KiB Swap: 4193276 total, 0 used, 4193276 free,
> 1135904 cached
>
>
>
> On "Linux version 3.11.6-1-ARCH
> (nobody@var-lib-archbuild-extra-x86_64-thomas) (gcc version 4.8.1
> 20130725 (prerelease) (GCC) ) #1 SMP PREEMPT Fri Oct 18 23:22:36 CEST
> 2013"
>
> Output of cpupower frequency-list while in KDE:
>
> analyzing CPU 0:
> driver: intel_pstate
> CPUs which run at the same hardware frequency: 0
> CPUs which need to have their frequency coordinated by software: 0
> maximum transition latency: 0.97 ms.
> hardware limits: 1.60 GHz - 5.90 GHz
> available cpufreq governors: performance, powersave
> current policy: frequency should be within 1.60 GHz and 5.90 GHz.
> The governor "powersave" may decide which speed to use
> within this range.
> current CPU frequency is 1.94 GHz (asserted by call to hardware).
> boost state support:
> Supported: yes
> Active: yes
> 25500 MHz max turbo 4 active cores
> 25500 MHz max turbo 3 active cores
> 25500 MHz max turbo 2 active cores
> 25500 MHz max turbo 1 active cores
>
> I'm attaching the config files of both kernels in case it's simply a
> configuration pebcak.
>
> --
>
> Joakim
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Problem: Possible regression in intel_pstate on 3.12
2013-12-16 9:08 ` Problem: Possible regression in intel_pstate on 3.12 Viresh Kumar
@ 2013-12-16 17:28 ` Dirk Brandewie
2014-01-12 1:43 ` Joakim Hernberg
0 siblings, 1 reply; 3+ messages in thread
From: Dirk Brandewie @ 2013-12-16 17:28 UTC (permalink / raw)
To: Viresh Kumar, Joakim Hernberg
Cc: Linux Kernel Mailing List, Rafael J. Wysocki,
linux-pm@vger.kernel.org
Hi Joakim,
Add the following patch to your v3.12 kernel and collect some data with the
command and send the resulting perf.data file:
perf record -a -c 1 -e power:pstate_sample sleep 10
TIA
--Dirk
commit b3dc2c2a106cea68e4c9c0f4747b15291113c4ae
Author: Dirk Brandewie <dirk.j.brandewie@intel.com>
Date: Mon Dec 2 09:56:46 2013 -0800
intel_pstate: Add trace point to report internal state.
Add perf trace event "power:pstate_sample" to report driver state to
aid in diagnosing issues reported against intel_pstate.
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
---
drivers/cpufreq/intel_pstate.c | 22 ++++++++++++++++++
include/trace/events/power.h | 53 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 75 insertions(+)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 5f1cbae..c4f14d1 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -50,6 +50,8 @@ static inline int32_t div_fp(int32_t x, int32_t y)
return div_s64((int64_t)x << FRAC_BITS, (int64_t)y);
}
+static u64 energy_divisor;
+
struct sample {
int32_t core_pct_busy;
u64 aperf;
@@ -512,6 +514,7 @@ static inline void intel_pstate_sample(struct cpudata *cpu)
rdmsrl(MSR_IA32_APERF, aperf);
rdmsrl(MSR_IA32_MPERF, mperf);
+
cpu->sample_ptr = (cpu->sample_ptr + 1) % SAMPLE_COUNT;
cpu->samples[cpu->sample_ptr].aperf = aperf;
cpu->samples[cpu->sample_ptr].mperf = mperf;
@@ -565,10 +568,24 @@ static inline void intel_pstate_adjust_busy_pstate(struct
cpudata *cpu)
static void intel_pstate_timer_func(unsigned long __data)
{
struct cpudata *cpu = (struct cpudata *) __data;
+ struct sample *sample;
+ u64 energy;
intel_pstate_sample(cpu);
+
+ sample = &cpu->samples[cpu->sample_ptr];
+ rdmsrl(MSR_PKG_ENERGY_STATUS, energy);
+
intel_pstate_adjust_busy_pstate(cpu);
+ trace_pstate_sample(fp_toint(sample->core_pct_busy),
+ fp_toint(intel_pstate_get_scaled_busy(cpu)),
+ cpu->pstate.current_pstate,
+ sample->mperf,
+ sample->aperf,
+ energy/energy_divisor,
+ sample->freq);
+
if (cpu->pstate.current_pstate == cpu->pstate.min_pstate) {
cpu->min_pstate_count++;
if (!(cpu->min_pstate_count % 5)) {
@@ -849,6 +866,7 @@ static int __init intel_pstate_init(void)
int cpu, rc = 0;
const struct x86_cpu_id *id;
struct cpu_defaults *cpu_info;
+ u64 units;
if (no_load)
return -ENODEV;
@@ -882,8 +900,12 @@ static int __init intel_pstate_init(void)
if (rc)
goto out;
+ rdmsrl(MSR_RAPL_POWER_UNIT, units);
+ energy_divisor = 1 << ((units >> 8) & 0x1f); /* bits{12:8} */
+
intel_pstate_debug_expose_params();
intel_pstate_sysfs_expose_params();
+
return rc;
out:
get_online_cpus();
diff --git a/include/trace/events/power.h b/include/trace/events/power.h
index cda100d..9e9475c 100644
--- a/include/trace/events/power.h
+++ b/include/trace/events/power.h
@@ -35,6 +35,59 @@ DEFINE_EVENT(cpu, cpu_idle,
TP_ARGS(state, cpu_id)
);
+TRACE_EVENT(pstate_sample,
+
+ TP_PROTO(u32 core_busy,
+ u32 scaled_busy,
+ u32 state,
+ u64 mperf,
+ u64 aperf,
+ u32 energy,
+ u32 freq
+ ),
+
+ TP_ARGS(core_busy,
+ scaled_busy,
+ state,
+ mperf,
+ aperf,
+ energy,
+ freq
+ ),
+
+ TP_STRUCT__entry(
+ __field(u32, core_busy)
+ __field(u32, scaled_busy)
+ __field(u32, state)
+ __field(u64, mperf)
+ __field(u64, aperf)
+ __field(u32, energy)
+ __field(u32, freq)
+
+ ),
+
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: Problem: Possible regression in intel_pstate on 3.12
2013-12-16 17:28 ` Dirk Brandewie
@ 2014-01-12 1:43 ` Joakim Hernberg
0 siblings, 0 replies; 3+ messages in thread
From: Joakim Hernberg @ 2014-01-12 1:43 UTC (permalink / raw)
To: Dirk Brandewie
Cc: Viresh Kumar, Linux Kernel Mailing List, Rafael J. Wysocki,
linux-pm@vger.kernel.org
Hello Dirk,
I don't seem to be able to apply this patch? For what kernel is it
meant, and is it complete?
Best wishes,
On Mon, 16 Dec 2013 09:28:19 -0800
Dirk Brandewie <dirk.brandewie@gmail.com> wrote:
> Hi Joakim,
>
> Add the following patch to your v3.12 kernel and collect some data
> with the command and send the resulting perf.data file:
> perf record -a -c 1 -e power:pstate_sample sleep 10
>
>
> TIA
> --Dirk
>
> commit b3dc2c2a106cea68e4c9c0f4747b15291113c4ae
> Author: Dirk Brandewie <dirk.j.brandewie@intel.com>
> Date: Mon Dec 2 09:56:46 2013 -0800
>
> intel_pstate: Add trace point to report internal state.
>
> Add perf trace event "power:pstate_sample" to report driver
> state to aid in diagnosing issues reported against intel_pstate.
>
> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
> ---
> drivers/cpufreq/intel_pstate.c | 22 ++++++++++++++++++
> include/trace/events/power.h | 53
> ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 75
> insertions(+)
>
> diff --git a/drivers/cpufreq/intel_pstate.c
> b/drivers/cpufreq/intel_pstate.c index 5f1cbae..c4f14d1 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -50,6 +50,8 @@ static inline int32_t div_fp(int32_t x, int32_t y)
> return div_s64((int64_t)x << FRAC_BITS, (int64_t)y);
> }
>
> +static u64 energy_divisor;
> +
> struct sample {
> int32_t core_pct_busy;
> u64 aperf;
> @@ -512,6 +514,7 @@ static inline void intel_pstate_sample(struct
> cpudata *cpu)
>
> rdmsrl(MSR_IA32_APERF, aperf);
> rdmsrl(MSR_IA32_MPERF, mperf);
> +
> cpu->sample_ptr = (cpu->sample_ptr + 1) % SAMPLE_COUNT;
> cpu->samples[cpu->sample_ptr].aperf = aperf;
> cpu->samples[cpu->sample_ptr].mperf = mperf;
> @@ -565,10 +568,24 @@ static inline void
> intel_pstate_adjust_busy_pstate(struct cpudata *cpu)
> static void intel_pstate_timer_func(unsigned long __data)
> {
> struct cpudata *cpu = (struct cpudata *) __data;
> + struct sample *sample;
> + u64 energy;
>
> intel_pstate_sample(cpu);
> +
> + sample = &cpu->samples[cpu->sample_ptr];
> + rdmsrl(MSR_PKG_ENERGY_STATUS, energy);
> +
> intel_pstate_adjust_busy_pstate(cpu);
>
> + trace_pstate_sample(fp_toint(sample->core_pct_busy),
> + fp_toint(intel_pstate_get_scaled_busy(cpu)),
> + cpu->pstate.current_pstate,
> + sample->mperf,
> + sample->aperf,
> + energy/energy_divisor,
> + sample->freq);
> +
> if (cpu->pstate.current_pstate == cpu->pstate.min_pstate) {
> cpu->min_pstate_count++;
> if (!(cpu->min_pstate_count % 5)) {
> @@ -849,6 +866,7 @@ static int __init intel_pstate_init(void)
> int cpu, rc = 0;
> const struct x86_cpu_id *id;
> struct cpu_defaults *cpu_info;
> + u64 units;
>
> if (no_load)
> return -ENODEV;
> @@ -882,8 +900,12 @@ static int __init intel_pstate_init(void)
> if (rc)
> goto out;
>
> + rdmsrl(MSR_RAPL_POWER_UNIT, units);
> + energy_divisor = 1 << ((units >> 8) & 0x1f); /* bits{12:8} */
> +
> intel_pstate_debug_expose_params();
> intel_pstate_sysfs_expose_params();
> +
> return rc;
> out:
> get_online_cpus();
> diff --git a/include/trace/events/power.h
> b/include/trace/events/power.h index cda100d..9e9475c 100644
> --- a/include/trace/events/power.h
> +++ b/include/trace/events/power.h
> @@ -35,6 +35,59 @@ DEFINE_EVENT(cpu, cpu_idle,
> TP_ARGS(state, cpu_id)
> );
>
> +TRACE_EVENT(pstate_sample,
> +
> + TP_PROTO(u32 core_busy,
> + u32 scaled_busy,
> + u32 state,
> + u64 mperf,
> + u64 aperf,
> + u32 energy,
> + u32 freq
> + ),
> +
> + TP_ARGS(core_busy,
> + scaled_busy,
> + state,
> + mperf,
> + aperf,
> + energy,
> + freq
> + ),
> +
> + TP_STRUCT__entry(
> + __field(u32, core_busy)
> + __field(u32, scaled_busy)
> + __field(u32, state)
> + __field(u64, mperf)
> + __field(u64, aperf)
> + __field(u32, energy)
> + __field(u32, freq)
> +
> + ),
> +
--
Joakim
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-01-12 1:43 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20131208172508.0cacabd0@tor.valhalla.alchemy.lu>
2013-12-16 9:08 ` Problem: Possible regression in intel_pstate on 3.12 Viresh Kumar
2013-12-16 17:28 ` Dirk Brandewie
2014-01-12 1:43 ` Joakim Hernberg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).