Comment 28 for bug 1480349

As Kristen mentions in post 18, the CORE_PERF_LIMIT_REASONS MSR is saying that the frequency is reduced below the operating system request due to PBM (Power Budget Management) limit. It seems odd that in such a reduced power consumption state the bit is still asserted.

Note that whenever the actual clock is below what has been asked for, the intel_pstate driver will drive down and ask for the lowest pstate, regardless of load. This is fundamental to the current control algorithm. The acpi-cpufreq frequency scaling driver doesn't have this problem, conceivably somewhat masking this issue. (not sure in this case. I.E. I am not sure if the frequency is locked at 37.5% of the minimum pstate regardless, or 37.5% of requested pstate. The performance mode test mentioned in the description would tend to indicate the former. One way to test is to force the use of the acpi-cpufreq driver by disabling the intel_pstate driver).

Myself, I would keep track of both what is being asked for and what the processor is actually giving. Example (on an older i7):

What is being asked for (the system is idle and min freq is 1.6 GHz):
# rdmsr --bitfield 15:8 -d -a 0x199
16
16
16
16
16
16
16
16

What the processor is actually giving (pstate 24 What? (I created a known issue for dramatic effect)):
# rdmsr --bitfield 15:8 -d -a 0x198
24
24
24
24
24
24
24
24