* 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).