Tweet
phoronix I have a i7-4980HQ Haswell Process in a 2015 MacBook Pro 11,5. I build custom kernels to address bugs and quirks on this platform, but have noticed this exact kind of performance discrepancy between p_state enabeld and cpufreq performance.
In p_state mode, my MacBook Pro consistently throttles back down from 2.8 GHz w Turbo Boost 3.8 GHz to a 800 MHz to 1600 MHz base state - on system start-up, everything is fast and happy. After a while thought, it makes sense that there should be thermal throttling; but even after the CPU is back at 50~60 degrees, the system fans have returned to ~50% of max speed, no amount of activity can provoke the CPU to increase the clock-speed past 1600 MHz on any given core. After a long period of the system being on, the processor can also be stuck at 800 MHz, with nothing else to do but to reboot to temporarily solve the issue. The performance differential is noticeable when building the Linux kernel from source, which is what got me started on this investigation. Toggling between the two governors (powersave/performance) is only a "recommendation" to the system, the CPU/firmware can decide to put itself into power-save mode.
If you look into how p_state is meant to work on Haswell, it turns out you have very little control over what the processor is doing, between your system firmware (which can manage the performance) and processor in built thermal protection. I suspect my specific problem may be related to the fact it's a Mac and whatever control the firmware has over the processor state is not communicating with the p_state driver correctly in the Linux kernel; or it's overriding any instruction from the OS if it's not OS X. No amount of activity can push the CPU back into performance mode, it never reaches it's base max frequency of 2.8 GHz. The result is that I get pretty great battery life out of the MacBook while travelling on a plane, but the lack of speedy performance for professional tasks is frustrating.
In the "Bay" family processors, this is meant to be controlled exclusively by the CPU with "Hardware P-State" (see hyperlink). The fact you've essentially replicated the performance problems I'm experiencing seems to indicate something is up.
If I disable p_state and return to cpufreq; I get all the scheduling control I could ever want; except for the fact Turbo Boost is disabled in this mode, which results in a locked max frequency of 2.8 GHz. At the moment, that is better than nothing, but getting the top of the line CPU to exploit the higher performance of turbo boost is disappointing, particularly when there appears to be no legitimate thermal reason that the CPU is getting locked while in p_state mode.
Just thought I'd add my two cents in; I've been using (sensors/cpuinfo) to monitor this during testing under work loads, and the reality is very sad. It may not be exactly related; but it did spike my interested enough to leave my experience in corroboration to your findings.
In p_state mode, my MacBook Pro consistently throttles back down from 2.8 GHz w Turbo Boost 3.8 GHz to a 800 MHz to 1600 MHz base state - on system start-up, everything is fast and happy. After a while thought, it makes sense that there should be thermal throttling; but even after the CPU is back at 50~60 degrees, the system fans have returned to ~50% of max speed, no amount of activity can provoke the CPU to increase the clock-speed past 1600 MHz on any given core. After a long period of the system being on, the processor can also be stuck at 800 MHz, with nothing else to do but to reboot to temporarily solve the issue. The performance differential is noticeable when building the Linux kernel from source, which is what got me started on this investigation. Toggling between the two governors (powersave/performance) is only a "recommendation" to the system, the CPU/firmware can decide to put itself into power-save mode.
If you look into how p_state is meant to work on Haswell, it turns out you have very little control over what the processor is doing, between your system firmware (which can manage the performance) and processor in built thermal protection. I suspect my specific problem may be related to the fact it's a Mac and whatever control the firmware has over the processor state is not communicating with the p_state driver correctly in the Linux kernel; or it's overriding any instruction from the OS if it's not OS X. No amount of activity can push the CPU back into performance mode, it never reaches it's base max frequency of 2.8 GHz. The result is that I get pretty great battery life out of the MacBook while travelling on a plane, but the lack of speedy performance for professional tasks is frustrating.
In the "Bay" family processors, this is meant to be controlled exclusively by the CPU with "Hardware P-State" (see hyperlink). The fact you've essentially replicated the performance problems I'm experiencing seems to indicate something is up.
If I disable p_state and return to cpufreq; I get all the scheduling control I could ever want; except for the fact Turbo Boost is disabled in this mode, which results in a locked max frequency of 2.8 GHz. At the moment, that is better than nothing, but getting the top of the line CPU to exploit the higher performance of turbo boost is disappointing, particularly when there appears to be no legitimate thermal reason that the CPU is getting locked while in p_state mode.
Just thought I'd add my two cents in; I've been using (sensors/cpuinfo) to monitor this during testing under work loads, and the reality is very sad. It may not be exactly related; but it did spike my interested enough to leave my experience in corroboration to your findings.
Code:
cpu MHz : 800.000 cpu MHz : 800.000 cpu MHz : 800.000 cpu MHz : 800.000 cpu MHz : 800.000 cpu MHz : 800.000 cpu MHz : 800.000 cpu MHz : 800.000 Left side : 3035 RPM (min = 2160 RPM, max = 6156 RPM) Right side : 2800 RPM (min = 2000 RPM, max = 5700 RPM) Core 0: +61.0°C (high = +84.0°C, crit = +100.0°C) Core 1: +67.0°C (high = +84.0°C, crit = +100.0°C) Core 2: +60.0°C (high = +84.0°C, crit = +100.0°C) Core 3: +63.0°C (high = +84.0°C, crit = +100.0°C)
Comment