[SOLVED] intel_pstate frequencies changing permanently

rebootl · 2013-06-20 15:33:07

Hi

After introduction of intel_pstate, I think I got it with Kernel version 3.9.2, it worked fine. The frequency was reported as 782MHz most of the time. And I was very happy with it...

But since Kernel 3.9.3 now the frequencies are changing permanently. For example this outputs:

Every 10.0s: grep "cpu MHz" /proc/c Thu Jun 20 17:22:19 2013

cpu MHz         : 1150.000
cpu MHz         : 1357.000
cpu MHz         : 2576.000
cpu MHz         : 2047.000

Every 10.0s: grep "cpu MHz" /proc/c Thu Jun 20 17:22:29 2013

cpu MHz         : 805.000
cpu MHz         : 2024.000
cpu MHz         : 1633.000
cpu MHz         : 2438.000

Every 10.0s: grep "cpu MHz" /proc/c Thu Jun 20 17:22:39 2013

cpu MHz         : 874.000
cpu MHz         : 1725.000
cpu MHz         : 2116.000
cpu MHz         : 1656.000

Doing nothing than writing this post in firefox...
Other output methods, cpupower, /sys/devices/system/cpu... report the same.
Even when doing nothing than watching the frequencies in a terminal they change permanently...

Is this the normal behaviour ? The behaviour I got with 3.9.2 described above seemed a lot saner to me...

cpupower:

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: 800 MHz - 2.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 2.90 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 1.13 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
analyzing CPU 1:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 0.97 ms.
  hardware limits: 800 MHz - 2.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 2.90 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 1.45 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
analyzing CPU 2:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 2
  CPUs which need to have their frequency coordinated by software: 2
  maximum transition latency: 0.97 ms.
  hardware limits: 800 MHz - 2.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 2.90 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 1.29 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
analyzing CPU 3:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 3
  CPUs which need to have their frequency coordinated by software: 3
  maximum transition latency: 0.97 ms.
  hardware limits: 800 MHz - 2.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 2.90 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 782 MHz (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

Edit:
I deactivated cpupower.service since I got intel_pstate.
And /proc/cpuinfo:

processor    : 0
vendor_id    : GenuineIntel
cpu family    : 6
model        : 42
model name    : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
stepping    : 7
microcode    : 0x1a
cpu MHz        : 1173.000
cache size    : 3072 KB
physical id    : 0
siblings    : 4
core id        : 0
cpu cores    : 2
apicid        : 0
initial apicid    : 0
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips    : 4591.09
clflush size    : 64
cache_alignment    : 64
address sizes    : 36 bits physical, 48 bits virtual
power management:

processor    : 1
vendor_id    : GenuineIntel
cpu family    : 6
model        : 42
model name    : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
stepping    : 7
microcode    : 0x1a
cpu MHz        : 782.000
cache size    : 3072 KB
physical id    : 0
siblings    : 4
core id        : 0
cpu cores    : 2
apicid        : 1
initial apicid    : 1
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips    : 4591.09
clflush size    : 64
cache_alignment    : 64
address sizes    : 36 bits physical, 48 bits virtual
power management:

processor    : 2
vendor_id    : GenuineIntel
cpu family    : 6
model        : 42
model name    : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
stepping    : 7
microcode    : 0x1a
cpu MHz        : 1219.000
cache size    : 3072 KB
physical id    : 0
siblings    : 4
core id        : 1
cpu cores    : 2
apicid        : 2
initial apicid    : 2
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips    : 4591.09
clflush size    : 64
cache_alignment    : 64
address sizes    : 36 bits physical, 48 bits virtual
power management:

processor    : 3
vendor_id    : GenuineIntel
cpu family    : 6
model        : 42
model name    : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
stepping    : 7
microcode    : 0x1a
cpu MHz        : 1173.000
cache size    : 3072 KB
physical id    : 0
siblings    : 4
core id        : 1
cpu cores    : 2
apicid        : 3
initial apicid    : 3
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips    : 4591.09
clflush size    : 64
cache_alignment    : 64
address sizes    : 36 bits physical, 48 bits virtual
power management:

Last edited by rebootl (2013-06-21 19:17:10)

WonderWoofy · 2013-06-20 16:01:41

The frequency of your processors experience changes in the order of microseconds. So even though it appeared as though your frequency was staying pretty consistent before, I would venture to say that it was probably not as steady as you may have thought it was. The intel_pstate driver is intended to do away with ondemand because ondemand required that the processor actually meed some kind of threshold to go from slowest to fastest. This threshold was determined to be met in userspace, so the change was ultimately pretty slow (in terms of the speed at which a cpu can change freq). This made for potentially far worse efficiency powerwise, and also far worse efficiency speed wise, because it would stay in the lowest frequency for much longer than it actually should have been. So intel_pstate is anattempt to fix that by letting the processor decide what frequency it should be at, andhave this all done at a muh lower level. Therefore, the changes are faster and ideally, more power efficient.

Just because the processor does not report that it is at is lowest frequency does not mean that it is not in idle for a significant portion of the time. You are looking at /proc/cpuinfo, which might make a good report of a single moment, but what you need is to see what portions of time the processor is staying in the deeper sleep states (c6 and c7). Powertop is one tool that can give a general overview, but for reasons I can't remember it has been deemed unable to be truly accurate in its measurement of frequency and time spent in sleep states. So for intel processors there is the i7z tool which can give much more reliable info (apparently). Use that and see what percentage of time your processor stays in C7. When doing things like answering email or writing this post, mine stays in C7 for >97% of the time.

rebootl · 2013-06-20 16:56:44

Okay, I understand about the point of intel_pstate and I believe it's better than ondemand, which I never liked anyways...
But I was talking about intel_pstate only.

And: Using i7z with Kernel 3.9.2 (which already has intel_pstate) the frequencies are reported to be around 800MHz.

But with a later or current kernel the frequencies are reported between around 1100-1700MHz or even higher.

(And I also believe that the temps are some degrees higher. I believe I had around 43°C earlier where as right now I have 50°C.)

For the idle times I get about the same results as you. But I still don't understand the difference in the frequencies...

Edit: Output of i7z:

Cpu speed from cpuinfo 2294.00Mhz
cpuinfo might be wrong if cpufreq is enabled. To guess correctly try estimating via tsc
Linux's inbuilt cpu_khz code emulated now
True Frequency (without accounting Turbo) 2294 MHz
  CPU Multiplier 23x || Bus clock frequency (BCLK) 99.74 MHz

Socket [0] - [physical cores=2, logical cores=4, max online cores ever=2]
  TURBO ENABLED on 2 Cores, Hyper Threading ON
  Max Frequency without considering Turbo 2393.74 MHz (99.74 x [24])
  Max TURBO Multiplier (if Enabled) with 1/2/3/4 Cores is  29x/27x/27x/27x
  Real Current Frequency 1389.06 MHz [99.74 x 13.93] (Max of below)
        Core [core-id]  :Actual Freq (Mult.)      C0%   Halt(C1)%  C3 %   C6 %   C7 %  Temp
        Core 1 [0]:       1265.54 (12.69x)      7.34    9.89    1.75       1    83.3    47
        Core 2 [2]:       1389.06 (13.93x)         1    1.02       1       0    97.5    47





C0 = Processor running without halting
C1 = Processor running with halts (States >C0 are power saver)
C3 = Cores running with PLL turned off and core cache turned off
C6 = Everything in C3 + core state saved to last level cache
  Above values in table are in percentage over the last 1 sec
[core-id] refers to core-id number in /proc/cpuinfo
'Garbage Values' message printed when garbage values are read
  Ctrl+C to exit

Maybe I'm too finical about this, or could this be an issue ?

Could you tell me what your frequency behaviour looks like, is it the same/similar?

Thanks

Last edited by rebootl (2013-06-20 18:18:20)

WonderWoofy · 2013-06-20 22:17:31

I think that there have been some improvments in terms of performance and reporting since it was first enabled in the kernel. So maybe it is just now calculating it in a different way, or even simply reporting slightly more accurately what is going on? I'm not entirely sure why this would be happening. I think that the only reason you should worry (or suspect an issue) is if you see major power regressions. You have to remember that this thing (though ti works pretty well) is quite new, so things are going to be continually ironed out as time goes on.

On my machine, I have a max of 2.5GHz (3.1 Turbo) and a min of 1.2GHz. i7z seems to report that it hovers ~1.9-2.0GHz, though it is also telling me that it is spending some 97% of the time in C7. So I think this is probably similar to yours. Had I been using the ondemand stuff, it would have been reporting 1.2GHz to me. But unfortunately, I have no real comparison of what it was when we first got to 3.9. I also have an Ivy Bridge processor, so I self compiled the kernel to include the product code of my processor so the intel_pstate should be applied. This has been taken care of already in 3.10, but my initial tests found that my machine plays very very nicely with the intel_pstate driver.

zezadas · 2013-06-20 23:16:37

did you enable dynamick ticks, i was getting more temperature because nvidia not work very well with that, and i have a hybrid card

WonderWoofy · 2013-06-20 23:47:32

Are you talking about the full dynamic ticks option in the 3.10rc* kernel? If you had read that second part of post #4 a bit more closely, you would have seen taht although I mention 3.10 as adding support for intel_pstate with IVB, I actually "patched" the 3.9 kernel. I actually just modified the source by hand since it was a single line.

zezadas · 2013-06-21 13:43:35

TL;DR

just trying to help.

rebootl · 2013-06-21 19:06:14

@WonderWoofy

Well, okay, I believe this is the normal behaviour then, atm. I had a look at the changelog for Kernel 3.9.3, although I don't understand most of the things written there, there were some changes on intel_pstate, probably influencing the calculation results.
Thanks

@zezadas

No, I didn't enable this, at least not that I would know about. I have a disabled radeon DGP.
Thanks

ValdikSS · 2013-06-24 11:41:50

I have made some tests and all I can say is intel_pstate/powersave is worse
than ondemand.

No network, minimum brightness, running KDE and Skype (offline):
ondemand: 6.66W, intel_pstate/powersave: 6.86W

No network, minimum brightness, running KDE, Skype and Amarok with music
playing:
ondemand: 9.71W, intel_pstate/powersave: 9.79W

ANOKNUSA · 2013-06-24 12:54:47

ValdikSS wrote:

I have made some tests and all I can say is intel_pstate/powersave is worse
than ondemand.

That'd be because you're using the wrong governor. 'Performance' is intended to be the default setting with intel_pstate.

ValdikSS · 2013-06-24 13:28:28

ANOKNUSA wrote:

That'd be because you're using the wrong governor. 'Performance' is intended to be the default setting with intel_pstate.

Are you sure?

No network, minimum brightness, running KDE and Skype (offline):
intel_pstate/performance: 7.07W

No network, minimum brightness, running KDE, Skype and Amarok with music:
intel_pstate/performance: 10.3W

WonderWoofy · 2013-06-24 15:21:47

You should read this: https://plus.google.com/114657443111661 … Ln9T4ehywL to understand why things have changed the way they have. Again, if you are seeing a massive power regression, I can't say it would be a bad idea to continue to use acpi_cpufreq for a bit longer while things get smoothed out. But they are definitely undergoing heavy changes since they are so new. So if you disable the intel_sptate driver, I would recommend at least giving it a try every kernel update. Apparently, as of 3.10, there have been even greater improvements and bug fixes. So it is not surprsing that we are still hearing of issues like yours, ValdikSS, since our repos contain the current stable kernel, which is always a little ways behind the git/rc kernels.

ValdikSS · 2014-01-12 04:50:05

I'm running 3.12.7 and ondemand is still better for me than intel_pstate.

Gusar · 2014-01-12 11:06:19

Please define "better". Though, contrary to what was said above, powersave is the governor to use with pstate. It's the default, so unless you have a real reason to switch to performance, just leave it at the default.

ValdikSS · 2014-01-12 11:10:07

Gusar wrote:

Please define "better". Though, contrary to what was said above, powersave is the governor to use with pstate. It's the default, so unless you have a real reason to switch to performance, just leave it at the default.

I use intel_pstate with powersave and it gives me less work time on battery than acpi/ondemand, powertop reports that it consumes more energy than with acpi/ondemand and the laptop's fan is running fast almost constantly while with acpi/ondemand it usually running slow (quiet).

Gusar · 2014-01-12 17:05:45

That's a much better answer. Now it'd be good to take a step further - report upstream, work with them to figure out what the issue is.

My experience with pstate has been much better. Ok I'm on a desktop, so there's no battery life to observe, but the CPU temp is the same as it was with acpi/ondemand, while compiling stuff has gotten faster (though that could be because ondemand was b0rked before 3.12), and overall the system is more responsive.

ValdikSS · 2014-01-12 17:09:19

Gusar wrote:

Now it'd be good to take a step further - report upstream, work with them to figure out what the issue is

I did it and quite active: https://bugzilla.kernel.org/show_bug.cgi?id=58801#c19
Some people confirm that they have the same behavior as on my laptop. I don't know what can I do because this bug is closed on bugzilla and developers says that everything is ok.

Gusar · 2014-01-12 18:02:53

The problem with that bug is that it's about frequencies. But high freqs are not the problem, because the processor is at the shown freq only in the C0 state. Comment #17 explains the situation very well. Then you join the discussion with a completely different issue. Even later, when Christoph says he's seeing the same as you, he still talks about freqencies and is wrong in thinking his machine is at the high frequency all the time. It's not. A high freq won't cause more heat when the machine is at that freq for less than 1% of the time.

There is likely a real issue somewhere, but it seems limited to specific machines, and it's unrelated to what's in that bug. I'm thinking it's about the interaction between the machine's fan management and pstate. Or some other platform-specific management. The real bug might not even be in pstate, it's just that pstate exposes it.

Opening a new bug that goes from this angle would be more productive I think. And that would require giving more information, like which laptop vendor, and which platform-specific modules (like for example thinkpad_acpi) are loaded. Then gather such info from more people. Would be interesting to see if those with issues have the same brand of laptop, or even the same series of laptop.

Last edited by Gusar (2014-01-12 18:07:03)

Arch Linux

#1 2013-06-20 15:33:07

[SOLVED] intel_pstate frequencies changing permanently

#2 2013-06-20 16:01:41

Re: [SOLVED] intel_pstate frequencies changing permanently

#3 2013-06-20 16:56:44

Re: [SOLVED] intel_pstate frequencies changing permanently

#4 2013-06-20 22:17:31

Re: [SOLVED] intel_pstate frequencies changing permanently

#5 2013-06-20 23:16:37

Re: [SOLVED] intel_pstate frequencies changing permanently

#6 2013-06-20 23:47:32

Re: [SOLVED] intel_pstate frequencies changing permanently

#7 2013-06-21 13:43:35

Re: [SOLVED] intel_pstate frequencies changing permanently

#8 2013-06-21 19:06:14

Re: [SOLVED] intel_pstate frequencies changing permanently

#9 2013-06-24 11:41:50

Re: [SOLVED] intel_pstate frequencies changing permanently

#10 2013-06-24 12:54:47

Re: [SOLVED] intel_pstate frequencies changing permanently

#11 2013-06-24 13:28:28

Re: [SOLVED] intel_pstate frequencies changing permanently

#12 2013-06-24 15:21:47

Re: [SOLVED] intel_pstate frequencies changing permanently

#13 2014-01-12 04:50:05

Re: [SOLVED] intel_pstate frequencies changing permanently

#14 2014-01-12 11:06:19

Re: [SOLVED] intel_pstate frequencies changing permanently

#15 2014-01-12 11:10:07

Re: [SOLVED] intel_pstate frequencies changing permanently

#16 2014-01-12 17:05:45

Re: [SOLVED] intel_pstate frequencies changing permanently

#17 2014-01-12 17:09:19

Re: [SOLVED] intel_pstate frequencies changing permanently

#18 2014-01-12 18:02:53

Re: [SOLVED] intel_pstate frequencies changing permanently

Board footer