Bug 65591

Summary: intel_pstate: Haswell CPU is not going to powersafe mode.
Product: Power Management Reporter: tomasi (tomas.ivanek)
Component: intel_pstateAssignee: Srinivas Pandruvada (srinivas.pandruvada)
Status: CLOSED INSUFFICIENT_DATA    
Severity: normal CC: alan, da_audiophile, dietmar.hummel, dsmythies, kepler-milden-nates-haves, lenb, liquid.acid, martin.kupec, rui.zhang, shawn.starr, szg00000, tianyu.lan, yu.c.chen
Priority: P1    
Hardware: Intel   
OS: Linux   
Kernel Version: 3.12.0-031200-generic Subsystem:
Regression: No Bisected commit-id:
Attachments: powertop idle stats
turbostat -d dump
Turbostat reaching PC7 wake up returns to PC2
PC7 powertop frequency table

Description tomasi 2013-11-24 08:25:31 UTC 
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>
Comment 1 Dirk Brandewie 2013-11-26 18:37:56 UTC 
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.
Comment 2 tomasi 2013-11-26 21:03:02 UTC 
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
Comment 3 Dirk Brandewie 2013-11-26 21:34:28 UTC 
(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
Comment 4 tomasi 2013-11-26 23:04:56 UTC 
Created attachment 116291 [details]
powertop idle stats
Comment 5 tomasi 2013-11-26 23:08:10 UTC 
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
Comment 6 tomasi 2013-11-28 08:14:08 UTC 
Shall I provide another info?
Still looks like a bug to me.
Comment 7 Dirk Brandewie 2013-12-02 16:27:04 UTC 
(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.
Comment 8 tomasi 2013-12-02 19:09:40 UTC 
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"
Comment 9 Martin Kupec 2014-01-16 21:33:15 UTC 
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.
Comment 10 tomasi 2014-01-16 21:37:05 UTC 
For suspend/resume problem, there is already defect opened
https://bugzilla.kernel.org/show_bug.cgi?id=66581
Comment 11 Tobias Jakobi 2014-06-29 13:36:47 UTC 
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.
Comment 12 Tobias Jakobi 2014-09-10 06:43:36 UTC 
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.
Comment 13 tomasi 2014-11-09 10:24:09 UTC 
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
Comment 14 da_audiophile 2015-02-20 23:23:25 UTC 
It still doesn't work... I opened the following not yet finding this report:
https://bugzilla.kernel.org/show_bug.cgi?id=93521
Comment 15 Chen Yu 2015-12-17 08:43:39 UTC 
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
Comment 16 Doug Smythies 2015-12-17 16:32:50 UTC 
(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.
Comment 17 Srinivas Pandruvada 2015-12-17 20:58:11 UTC 
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.
Comment 18 Doug Smythies 2015-12-17 23:21:09 UTC 
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
Comment 19 Srinivas Pandruvada 2015-12-18 00:43:15 UTC 
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.
Comment 20 Doug Smythies 2015-12-18 06:29:49 UTC 
Srinivas: Yes, Agreed.
Comment 21 Chen Yu 2016-03-15 07:12:41 UTC 
Please reopen and provide trace data as Srinivas suggested ar Comment19 if you can reproduce on latest kernel.
Comment 22 Shawn Starr 2016-12-03 06:00:47 UTC 
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.
Comment 23 Shawn Starr 2016-12-03 06:01:22 UTC 
Created attachment 246731 [details]
turbostat -d dump

turbostat -d dump
Comment 24 Shawn Starr 2016-12-03 06:02:43 UTC 
Please reopen so this can be diagnosed, I cannot reopen the bug.
Comment 25 Shawn Starr 2016-12-03 06:16:45 UTC 
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)
Comment 26 Shawn Starr 2016-12-03 06:50:45 UTC 
Created attachment 246751 [details]
PC7 powertop frequency table