I’m using a DELL E7440 Haswell platform with dual OS: Win 8.1 and Ubuntu (3.16). While measuring Package C-state over Windows, I get ~90% PC7 during idle periods. However, when measuring Package C-states over Ubuntu I get only as high as PC3 with nearly 0% residency, while the cores are 99% at C7. I tried to investigate the issue and noticed that the MSR 0xe2 (MSR_PKG_CST_CONFIG_CONTROL) has Package C-State Limit set to 0 (with CFG lock set).
- Is this configuration preventing Linux from entering high Package C-states?
- Any idea how Windows manages to reach PC7 despite this configuration?
Sorry to not reply sooner. I missed the initial posting.
I've seen similar issues with Ubuntu. Can you get powertop from 01.org and run 'powertop --auto-tune'? This should improve the situaltion although you will have to run it each time you boot.
Powertop displays a screen showing which device settings aren't optimal and you can change each one individually (and see which one lets the system start using higher cstates.
Also try updating the BIOS.
I have a dual booted (windows & ubuntu) haswell laptop that won't suspend when I close the lid. After running powertop the system can get into C10 some and the power usage with the lid closed is better but it still ridiculously high (at 1-6 watts). The win8.1 OS on the same system goes into C10 almost 100% when the lid is closed and typically uses 0.1 watts with the lid closed. This is the connected standby behavior. The 0.1 watts even accounts for the system waking once a minute to check for emails etc.
Unfortunately, it is not a simple powertop --auto-tune issue. It appears that the BIOS is preventing the power save (sort of) and Linux comply and behaves "correctly". See https://bugzilla.kernel.org/show_bug.cgi?id=85401 and https://bugzilla.kernel.org/show_bug.cgi?id=85621.
I assume that most notebooks won't ship until they work well with Windows and the BIOS is tuned to meet Windows behavior/requirements (whatever they are). As per Linux, no one bothers to tune the BIOS/OS for Linux notebooks, which make some sense as not many Linux notebooks are out there.
Not that I like beating a dead horse... maybe posting pictures of the dead horse is okay? Below are some graphs from my recent presentation "I know what you did when the lights went out (when the laptop lid is closed)".
First picture is my dual-booting Ubuntu/Win81 haswell-based laptop before 'powertop --autotune' (powertop 2.7, Ubuntu 3.13.0-46-generic). The picture is from my upcoming (if I ever stop posting to this forum) release of IPPET. It shows the power usage when the lid is closed on the laptop. It ranges between about 3-10 watts during the 3100 seconds that the lid is closed. The 'Package overhead = RAPL Package power - RAPL CPU power - RAPL GPU power'. The 'non-pkg bat discharging = battery usage - package power' where package power is the RAPL package power. CPU is RAPL CPU power, GPU is RAPL GPU power. The Cstate %Residency graph shows that the package only hits C2. Just closing the lid, I've often found that the system has drained the battery when I get back to the system.
The next picture below shows the ubuntu-booted system after running powertop 2.7. Now the power usage ranges between about 1-7 watts. So much improved but still much higher than it should be. The package Cstates are much improved. Now the system can hit C3, C7, and C10. But I have to run 'powertop --auto-tune' every time I boot.
Next below we show Windows 8.1 which goes into connected standby (CS). In CS Windows suspends desktop apps and once a minute allows services to run and quickly check things (such as email). You can see that usually Win81 uses about 0.1 watts with spikes to about 1 watt. The package Cstates are almost entirely C10.
All these pretty pictures aside, it remains an open question for me what sort of priority the power usage by Linux-based laptops might be for Linux developers. I just don't know how important the Linux-based laptop market is compared to reducing the power usage of Linux-based servers and tablets/phones. OS X does fine on Haswell (in case anyone is wondering).