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 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1480349 Title: Intel Microcode Breaks frequency scaling in Xeon® E5-2687W v3 & E5-1650 v3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1480349/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
