CPU speed is not going to powersafe mode - to 800 Mhz. It' always >1.6 GHz Minfreq is defined as 800000. Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz root@dell-xps:/sys/devices/system/cpu/cpu0/cpufreq# grep "" * affected_cpus:0 cpuinfo_cur_freq:1878812 cpuinfo_max_freq:2600000 cpuinfo_min_freq:800000 cpuinfo_transition_latency:4294967295 related_cpus:0 scaling_available_governors:performance powersave scaling_driver:intel_pstate scaling_governor:powersave scaling_max_freq:2600000 scaling_min_freq:800000 scaling_setspeed:<unsupported>
Could you run the following experiment as root: cd /sys/devices/system/cpu/intel_pstate/ cat cat min_perf_pct > max_perf_pct turbostat sleep 300 echo 100 > max_perf_pct turbostat sleep 300 and post the output of the two turbostat runs.
root@t440s:/home/bio/Desktop/defect# cd /sys/devices/system/cpu/intel_pstate/ root@t440s:/sys/devices/system/cpu/intel_pstate# cat min_perf_pct > max_perf_pct # now the frequency changed to 0.8 Ghz (I see that in conky) turbostat sleep 300 core CPU %c0 GHz TSC %c1 %c3 %c6 %pc3 %pc6 6.03 0.80 2.29 91.54 1.85 0.57 0.00 0.00 0 0 6.61 0.80 2.29 91.24 1.87 0.29 0.00 0.00 0 1 6.31 0.80 2.29 91.53 1.87 0.29 0.00 0.00 1 2 5.54 0.80 2.29 91.77 1.83 0.86 0.00 0.00 1 3 5.68 0.80 2.29 91.63 1.83 0.86 0.00 0.00 300.002049 sec echo 100 > max_perf_pct # cpu freq is now from 1.6 Ghz to 2.5 Ghz turbostat sleep 300 core CPU %c0 GHz TSC %c1 %c3 %c6 %pc3 %pc6 3.31 1.93 2.29 94.71 1.35 0.63 0.00 0.00 0 0 3.75 1.96 2.29 94.70 1.20 0.35 0.00 0.00 0 1 3.16 2.12 2.29 95.29 1.20 0.35 0.00 0.00 1 2 3.00 1.81 2.29 94.59 1.50 0.91 0.00 0.00 1 3 3.35 1.83 2.29 94.24 1.50 0.91 0.00 0.00 300.001034 sec P.S. I had troubles to compile turbostat from here: https://github.com/torvalds/linux/blob/master/tools/power/x86/turbostat/turbostat.c i got errors: root@t440s:/home/bio/Desktop/defect# gcc -o turbostat turbostat.c turbostat.c: In function ‘get_counters’: turbostat.c:862:20: error: ‘MSR_SMI_COUNT’ undeclared (first use in this function) turbostat.c:862:20: note: each undeclared identifier is reported only once for each function it appears in turbostat.c:887:20: error: ‘MSR_CORE_C1_RES’ undeclared (first use in this function) turbostat.c:896:20: error: ‘MSR_CORE_C3_RESIDENCY’ undeclared (first use in this function) turbostat.c:901:20: error: ‘MSR_CORE_C6_RESIDENCY’ undeclared (first use in this function) turbostat.c:906:20: error: ‘MSR_CORE_C7_RESIDENCY’ undeclared (first use in this function) turbostat.c:921:20: error: ‘MSR_PKG_C3_RESIDENCY’ undeclared (first use in this function) so I took turbostat from here: http://code.google.com/p/ast-linux-patches/source/browse/tools/power/x86/turbostat/turbostat.c?spec=svna829eb4d7e08b316e2d48880ecab3630497f300f&r=a829eb4d7e08b316e2d48880ecab3630497f300f
(In reply to tomasi from comment #2) > root@t440s:/home/bio/Desktop/defect# cd > /sys/devices/system/cpu/intel_pstate/ > root@t440s:/sys/devices/system/cpu/intel_pstate# cat min_perf_pct > > max_perf_pct > # now the frequency changed to 0.8 Ghz (I see that in conky) > > turbostat sleep 300 > core CPU %c0 GHz TSC %c1 %c3 %c6 %pc3 %pc6 > 6.03 0.80 2.29 91.54 1.85 0.57 0.00 0.00 > 0 0 6.61 0.80 2.29 91.24 1.87 0.29 0.00 0.00 > 0 1 6.31 0.80 2.29 91.53 1.87 0.29 0.00 0.00 > 1 2 5.54 0.80 2.29 91.77 1.83 0.86 0.00 0.00 > 1 3 5.68 0.80 2.29 91.63 1.83 0.86 0.00 0.00 > 300.002049 sec > > echo 100 > max_perf_pct > # cpu freq is now from 1.6 Ghz to 2.5 Ghz > > turbostat sleep 300 > core CPU %c0 GHz TSC %c1 %c3 %c6 %pc3 %pc6 > 3.31 1.93 2.29 94.71 1.35 0.63 0.00 0.00 > 0 0 3.75 1.96 2.29 94.70 1.20 0.35 0.00 0.00 > 0 1 3.16 2.12 2.29 95.29 1.20 0.35 0.00 0.00 > 1 2 3.00 1.81 2.29 94.59 1.50 0.91 0.00 0.00 > 1 3 3.35 1.83 2.29 94.24 1.50 0.91 0.00 0.00 > 300.001034 sec > > > P.S. > I had troubles to compile turbostat from here: > https://github.com/torvalds/linux/blob/master/tools/power/x86/turbostat/ > turbostat.c > Turbostat should inside of a kernel tree I have never tried to build it outside the tree where its source resides. The version you have is kind of old the newest version reports power as measured by the processor as well. The figure of merit in your results is the %c0 number where you processor is non-idle. Having a lower %c0 means you are consuming less energy. While the processor is idle the frequency is zero. Another thing in your results you are no getting into the deeper C states very often. Deeper C states save more energy because more part of the processor can be shut down. powertop will help you find the thngs that are keeping your system more awake than it may need to be. > i got errors: > root@t440s:/home/bio/Desktop/defect# gcc -o turbostat turbostat.c > turbostat.c: In function ‘get_counters’: > turbostat.c:862:20: error: ‘MSR_SMI_COUNT’ undeclared (first use in this > function) > turbostat.c:862:20: note: each undeclared identifier is reported only once > for each function it appears in > turbostat.c:887:20: error: ‘MSR_CORE_C1_RES’ undeclared (first use in this > function) > turbostat.c:896:20: error: ‘MSR_CORE_C3_RESIDENCY’ undeclared (first use in > this function) > turbostat.c:901:20: error: ‘MSR_CORE_C6_RESIDENCY’ undeclared (first use in > this function) > turbostat.c:906:20: error: ‘MSR_CORE_C7_RESIDENCY’ undeclared (first use in > this function) > turbostat.c:921:20: error: ‘MSR_PKG_C3_RESIDENCY’ undeclared (first use in > this function) > > so I took turbostat from here: > http://code.google.com/p/ast-linux-patches/source/browse/tools/power/x86/ > turbostat/turbostat. > c?spec=svna829eb4d7e08b316e2d48880ecab3630497f300f&r=a829eb4d7e08b316e2d48880 > ecab3630497f300f
Created attachment 116291 [details] powertop idle stats
Here is turbostat from kernel 3.12. There was need to download full kernel and compile turbostat. root@t440s:/sys/devices/system/cpu/intel_pstate# cat min_perf_pct > max_perf_pct root@t440s:/sys/devices/system/cpu/intel_pstate# /home/bio/Desktop/defect/kern/linux-3.12/tools/power/x86/turbostat/turbostat sleep 300 cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 CTMP PTMP %pc2 %pc3 %pc6 %pc7 %pc8 %pc9 %pc10 Pkg_W Cor_W GFX_W 1.82 0.80 2.29 0 11.29 1.44 0.45 85.00 44 45 74.88 0.00 0.00 0.00 0.00 0.00 0.00 3.05 0.08 0.03 0 0 1.78 0.80 2.29 0 5.46 1.22 0.49 91.05 44 45 74.88 0.00 0.00 0.00 0.00 0.00 0.00 3.05 0.08 0.03 0 1 1.45 0.80 2.29 0 5.80 1 2 2.38 0.80 2.29 0 16.61 1.65 0.40 78.96 41 1 3 1.68 0.80 2.29 0 17.31 300.002152 sec root@t440s:/sys/devices/system/cpu/intel_pstate# echo 100 > max_perf_pct root@t440s:/sys/devices/system/cpu/intel_pstate# /home/bio/Desktop/defect/kern/linux-3.12/tools/power/x86/turbostat/turbostat sleep 300 cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 CTMP PTMP %pc2 %pc3 %pc6 %pc7 %pc8 %pc9 %pc10 Pkg_W Cor_W GFX_W 2.11 2.02 2.29 0 8.16 1.22 0.53 87.98 46 48 59.20 0.00 0.00 0.00 0.00 0.00 0.00 3.61 0.31 0.11 0 0 2.11 2.03 2.29 0 5.86 1.28 0.82 89.93 46 48 59.20 0.00 0.00 0.00 0.00 0.00 0.00 3.61 0.31 0.11 0 1 2.59 1.96 2.29 0 5.39 1 2 2.06 2.14 2.29 0 10.50 1.16 0.23 86.04 46 1 3 1.69 1.97 2.29 0 10.88 300.000861 sec
Shall I provide another info? Still looks like a bug to me.
(In reply to tomasi from comment #5) > Here is turbostat from kernel 3.12. > There was need to download full kernel and compile turbostat. > > root@t440s:/sys/devices/system/cpu/intel_pstate# cat min_perf_pct > > max_perf_pct > root@t440s:/sys/devices/system/cpu/intel_pstate# > /home/bio/Desktop/defect/kern/linux-3.12/tools/power/x86/turbostat/turbostat > sleep 300 > cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 CTMP PTMP %pc2 > %pc3 %pc6 %pc7 %pc8 %pc9 %pc10 Pkg_W Cor_W GFX_W > 1.82 0.80 2.29 0 11.29 1.44 0.45 85.00 44 45 74.88 > 0.00 0.00 0.00 0.00 0.00 0.00 3.05 0.08 0.03 > 0 0 1.78 0.80 2.29 0 5.46 1.22 0.49 91.05 44 45 74.88 > 0.00 0.00 0.00 0.00 0.00 0.00 3.05 0.08 0.03 > 0 1 1.45 0.80 2.29 0 5.80 > 1 2 2.38 0.80 2.29 0 16.61 1.65 0.40 78.96 41 > 1 3 1.68 0.80 2.29 0 17.31 > 300.002152 sec > > root@t440s:/sys/devices/system/cpu/intel_pstate# echo 100 > max_perf_pct > root@t440s:/sys/devices/system/cpu/intel_pstate# > /home/bio/Desktop/defect/kern/linux-3.12/tools/power/x86/turbostat/turbostat > sleep 300 > cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 CTMP PTMP %pc2 > %pc3 %pc6 %pc7 %pc8 %pc9 %pc10 Pkg_W Cor_W GFX_W > 2.11 2.02 2.29 0 8.16 1.22 0.53 87.98 46 48 59.20 > 0.00 0.00 0.00 0.00 0.00 0.00 3.61 0.31 0.11 > 0 0 2.11 2.03 2.29 0 5.86 1.28 0.82 89.93 46 48 59.20 > 0.00 0.00 0.00 0.00 0.00 0.00 3.61 0.31 0.11 > 0 1 2.59 1.96 2.29 0 5.39 > 1 2 2.06 2.14 2.29 0 10.50 1.16 0.23 86.04 46 > 1 3 1.69 1.97 2.29 0 10.88 > 300.000861 sec Something is strange here these results don't match up with you previous results. Are you sure there was nothing else going on in the system for the second measurement? The real point is the less time you spend in C0 the less energy/power the CPU will consume. While the CPU is not in C0 the frequency is essentially zero. If you want to save power spending the most time possible in a deep C state (C3/C6) is desirable. Powertop will help you identify the things keeping your system awake and from reaching deep cstates. Your first results showed the CPU running ~50% less at the higher frequency which saves power.
Here are new results with new kernel 3.12.2. I tried to not do anything during 5 minutes. Linux t440s 3.12.2-031202-generic #201311291538 SMP Fri Nov 29 20:39:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Following processes were running: Top - 20:00:26 up 47 min, 1 user, load average: 0.05, 0.13, 0.13 Tasks: 203 total, 1 running, 201 sleeping, 0 stopped, 1 zombie Cpu(s): 1.0%us, 1.3%sy, 0.0%ni, 97.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 11993692k total, 2108128k used, 9885564k free, 95012k buffers Swap: 0k total, 0k used, 0k free, 826716k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1466 root 20 0 151m 19m 9388 S 3 0.2 1:13.96 Xorg 1903 bio 20 0 438m 100m 29m S 2 0.9 1:08.45 skype 5781 bio 20 0 501m 20m 10m S 1 0.2 0:02.89 xfce4-terminal 3881 root 20 0 678m 4832 3384 S 1 0.0 0:14.48 collectd 5678 bio 20 0 638m 8924 5684 S 1 0.1 0:27.47 conky 5766 bio 20 0 1508m 336m 30m S 0 2.9 0:30.62 opera 6792 root 20 0 17456 1520 1092 R 0 0.0 0:00.05 top 1 root 20 0 24588 2548 1376 S 0 0.0 0:01.09 init 0.8 Ghz: root@t440s:/home/bio/Desktop/defect/kern/linux-3.12/tools/power/x86/turbostat# ./turbostat sleep 300 cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 CTMP PTMP %pc2 %pc3 %pc6 %pc7 %pc8 %pc9 %pc10 Pkg_W Cor_W GFX_W 5.40 0.80 2.30 0 14.95 2.12 0.34 77.19 41 42 10.70 0.00 0.00 0.00 0.00 0.00 0.00 4.04 0.21 0.22 0 0 7.04 0.80 2.30 0 12.98 2.00 0.20 77.78 41 42 10.70 0.00 0.00 0.00 0.00 0.00 0.00 4.04 0.21 0.22 0 1 4.29 0.80 2.30 0 15.73 1 2 6.16 0.80 2.30 0 14.52 2.24 0.49 76.60 40 1 3 4.12 0.80 2.30 0 16.55 300.002572 sec 1.6GHz+ root@t440s:/home/bio/Desktop/defect/kern/linux-3.12/tools/power/x86/turbostat# ./turbostat sleep 300 cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 CTMP PTMP %pc2 %pc3 %pc6 %pc7 %pc8 %pc9 %pc10 Pkg_W Cor_W GFX_W 2.57 2.11 2.29 0 11.54 1.09 0.39 84.41 41 43 13.18 0.00 0.00 0.00 0.00 0.00 0.00 4.34 0.42 0.22 0 0 2.80 2.01 2.29 0 8.18 0.94 0.20 87.88 41 43 13.18 0.00 0.00 0.00 0.00 0.00 0.00 4.34 0.42 0.22 0 1 1.08 1.83 2.29 0 9.90 1 2 4.62 2.27 2.29 0 12.62 1.23 0.58 80.95 40 1 3 1.77 2.03 2.29 0 15.47 300.001366 sec Additionally, I had powertop (version 2.1) running: 0.8 Ghz: Battery reports discharging rate: 6.8, 7.10, 7.33, 7,07, 7.03 , 6.85, 7.12, W 1.6+ Ghz: Battery reports discharging rate: 7.44 , 7,54, 7.6, 7.5, 7.44, 7.34, W So, It's about 0.5W more with "echo 100 > max_perf_pct"
Hi, I do have the same problem. I have: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz and kernel 3.13.0-rc6 I did the turbostat test: cat min_perf_pct > max_perf_pct cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 CTMP PTMP %pc2 %pc3 %pc6 %pc7 %pc8 %pc9 %pc10 Pkg_W Cor_W GFX_W 2.51 0.80 2.39 0 2.91 0.10 0.11 94.37 47 50 87.94 0.00 0.00 0.00 0.00 0.00 0.00 3.78 0.09 0.05 0 0 2.89 0.80 2.39 0 2.53 0.13 0.09 94.35 47 50 87.94 0.00 0.00 0.00 0.00 0.00 0.00 3.78 0.09 0.05 0 1 1.98 0.80 2.39 0 3.44 1 2 3.39 0.80 2.39 0 2.02 0.07 0.12 94.39 47 1 3 1.79 0.80 2.39 0 3.63 300.001905 sec echo 100 > max_perf_pct cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 CTMP PTMP %pc2 %pc3 %pc6 %pc7 %pc8 %pc9 %pc10 Pkg_W Cor_W GFX_W 1.30 2.07 2.39 0 1.93 0.11 0.04 96.62 47 50 90.72 0.00 0.00 0.00 0.00 0.00 0.00 3.90 0.19 0.07 0 0 1.24 2.12 2.39 0 1.79 0.13 0.05 96.79 46 50 90.72 0.00 0.00 0.00 0.00 0.00 0.00 3.90 0.19 0.07 0 1 1.16 2.02 2.39 0 1.87 1 2 1.98 2.08 2.39 0 1.45 0.09 0.03 96.45 47 1 3 0.80 2.02 2.39 0 2.62 300.000904 sec I have additional problem. When I suspend and resume my laptop, than the average frequency is ~2.6MHz and the fan kicks in. I don't know it I should open separate bug it it will fit here.
For suspend/resume problem, there is already defect opened https://bugzilla.kernel.org/show_bug.cgi?id=66581
I have a similar problem here on a i7-4700HQ, kernel is 3.15.2. pstate doesn't go into lower modes, and even worse, it stays always at turbomode for each core, heating up the system like crazy.
Just a short note that this is fixed for me in 3.16.y. There is still a similar issue related to suspend/resume, which is tracked in bug #80651.
Hi, it's just me or it's still does't work? Just tried latest kernel and issue is still here. kernel version: Linux t440s 3.15.0-031500-generic #201406081435 SMP Sun Jun 8 18:36:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Guess I'm not alone, anybody else? https://bugzilla.kernel.org/show_bug.cgi?id=72211#c5
It still doesn't work... I opened the following not yet finding this report: https://bugzilla.kernel.org/show_bug.cgi?id=93521
Since there is no load on cpu(idle), turbostat measures the frequency for a very small portion of elapsed time: Bzy_MHz = small_cycles_c0/small_time_c0, it is not very reliable – particularly for short measurement intervals or very very low %Busy. So I think we should not rely on the values when cpu is in idle IMO, the same as sysfs's cpuinfo_cur_freq. Yu
(In reply to Chen Yu from comment #15) > Since there is no load on cpu(idle), turbostat measures the frequency for a > very small portion of elapsed time: > Bzy_MHz = small_cycles_c0/small_time_c0, > it is not very reliable – particularly for short measurement intervals or > very > very low %Busy. So I think we should not rely on the values when cpu is in > idle IMO, the same as sysfs's cpuinfo_cur_freq. > > Yu Chen, I disagree, particularly for sysfs's cpuinfo_cur_freq (not so sure about turbostat). I studied this exact issue extensively one time, albeit a couple of years ago now. I did the investigation because I had the exact same worry that you state. I never found a situation where the number of cycles was so low that one couldn't more or less trust the result, although it could become a little noisy. Keep in mind that if the CPU is really idle, then the intel_pstate driver will only run every few seconds, and as long as 4 seconds. I do not have a haswell processor, but I have accumulated a ton of trace data over the last year from people that do. It would take me awhile to find the minimum numbers, but so far I haven't found an aperf number less than 40000 or an mperf less than 80000. For my i7-2600K, without trying, I found an aperf and mpref around 30000, at a duration of 64 milliseconds, the CPU frequency at the time being very high, due to load on another CPU.
We should look at what we requested to further debug this issue. Doug may already have this. cd /sys/kernel/debug/tracing/events/power/pstate_sample/ echo 1 > enable Wait for few seconds cat /sys/kernel/debug/tracing/trace We can find out are we really requesting or some other issue.
Additionally, I think I did my initial analysis way back when the aperf and mperf samples were throwing out 8 least significant bits. I did a trace (via a different method than Srinivas mentions below) for 3.5 hours on my test server. The minimum aperf or mperf sample was: aperf: 32216 , mperf: 68458, duration 36 mSec, load 0.06 percent. (In reply to Srinivas Pandruvada from comment #17) > We should look at what we requested to further debug this issue. Doug may > already have this. > cd /sys/kernel/debug/tracing/events/power/pstate_sample/ > echo 1 > enable > > Wait for few seconds > > cat /sys/kernel/debug/tracing/trace > > We can find out are we really requesting or some other issue. Srinivas: The problem is that when these weird issues occur, it sometimes isn't good enough to observe what we requested, we have to also observe what we actually got. For an example from my system see: https://bugzilla.kernel.org/show_bug.cgi?id=66581#c53
Doug "The problem is that when these weird issues occur, it sometimes isn't good enough to observe what we requested, we have to also observe what we actually got. For an example from my system see:" The driver can only control what it requests. This is not guaranteed, we will get what we requested. In this case if on all cores we request only 800MHz and get 1.6GHz all the time, then there is some other factor beyond this driver control. I need to check with some others to see how we can know if SMM code or something else causing this. So this is important to know what we requested.
Srinivas: Yes, Agreed.
Please reopen and provide trace data as Srinivas suggested ar Comment19 if you can reproduce on latest kernel.
Reopening as this is affecting me also .. since i bought this laptop... 2015... 4.9.0-rc7 kernel (Dec 3rd code) from Linus Master # cd /sys/devices/system/cpu/intel_pstate/ # cat min_perf_pct > max_perf_pct # turbostat sleep 300 300.002260 sec CPU Avg_MHz Busy% Bzy_MHz TSC_MHz - 5 0.60 800 2893 0 3 0.43 800 2893 4 21 2.60 800 2893 1 2 0.25 800 2893 5 3 0.41 800 2893 2 3 0.41 800 2893 6 3 0.36 800 2893 3 2 0.21 800 2893 7 1 0.11 800 2893 # echo 100 > max_perf_pct # turbostat sleep 300 300.001725 sec CPU Avg_MHz Busy% Bzy_MHz TSC_MHz - 2 0.24 1044 2893 0 1 0.14 1044 2893 4 2 0.15 1217 2893 1 1 0.11 1104 2893 5 6 0.61 971 2893 2 3 0.29 979 2893 6 2 0.24 1031 2893 3 1 0.12 927 2893 7 3 0.25 1230 2893 It is stuck in PC2 and only has 2% PC6, while i've set every option in Powertop to Good power status. attached is turbostat -d output.
Created attachment 246731 [details] turbostat -d dump turbostat -d dump
Please reopen so this can be diagnosed, I cannot reopen the bug.
Created attachment 246741 [details] Turbostat reaching PC7 wake up returns to PC2 Leaving it idle more, it went into PC7, waking it up it returns to PC2. I should note, the LVDS/eDP display is powered off via drm.video= option and display is being sent to VGA out at 1920x1200 resolution, according to Intel 1920x1200 is minimum power for PC6 at least for 4th gen CPUs+ (http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/4th-gen-core-family-mobile-u-y-processor-lines-vol-1-datasheet.pdf Section 4.2.6)
Created attachment 246751 [details] PC7 powertop frequency table