Battery life

[Dunedan]

I played a bit around with power saving on my MacBookPro13,2 and I'm quite puzzled.

I simply tried to reach the lowest possible power consumption as a base line, but weren't able to reach less than ~9W! And that's with display at the lowest brightness level, switched off TouchBar, no external devices, no running applications, all options set suggested by powertop, (no dGPU as the MacBookPro13,2 got none) ...

Apple claims 10 hours of wireless surfing or movie playback with MacOS. As the battery is 49,2Wh that means they get the power consumption down to ~5W with a brighter display backlight and processors doing actual work. So it'd be fair to say they are 50% more efficient than Linux.

What seems to be missing under Linux is power management of the NVMe SSD. At least APST doesn't seem to be supported (at least nvme id-ctrl /dev/nvme0 shows no additional power state beside ps 0 with Linux 4.12rc5). That could be the reason for a few watts of additional power usage, but I doubt it could be responsible for 4W. Anyway I'm pretty sure the SSD supports some kind of power management, so this could be an area to look into further.

What are your experiences? Any ideas where we can get additional savings from?

[romu70]

I have serious doubts about the 10 hours battery life claim. Maybe when you browse static pages, but modern html5 with a lot of embedded Js consumes a lot of power. I've never reached 10 hours with my 13,1. I took the habit of setting the screen brightness at 50%, but that's not enough to get a full day of batterie.

[Dunedan]

I have serious doubts about the 10 hours battery life claim. Maybe when you browse static pages, but modern html5 with a lot of embedded Js consumes a lot of power. I've never reached 10 hours with my 13,1. I took the habit of setting the screen brightness at 50%, but that's not enough to get a full day of batterie.

Depends on the workload. I imagine for browsing static web pages or other light workloads that absolutely legit. You lost as soon as you start doing serious work, as the battery will drain very quickly. That's disappointing, but expected given the capacity of the battery.

The German publication "Mac & i" yesterday even claimed they get ~20 hours out of the 13" MBP 2016 and 2017 under MacOS. That made me laugh. We'll probably never reach double digit hours of battery life with Linux but we need at least to try.

Of course such measurements are always done with dimmed display, but unless you're in bright sunlight, even 50% brightness is more than enough with these displays.

[Dunedan]

Regarding power saving modes of the SSD I noticed some entries in the DSDT, which relate to that. The current efforts to enable the Linux kernel to read Apples _DSM-properties (https://github.com/cb22/macbook12-spi-driver/pull/29#issuecomment-309202586) seem to be a dependency for using that.

I also noticed something else while reading through Apples website for the MacBook Pro:

The display in the MacBook Pro is the best ever in a Mac notebook. It features bright LED backlighting and a high contrast ratio, delivering deep blacks and bright whites. Its large pixel aperture and variable refresh rate make it power efficient.

Sounds like they support Panel Self Refresh (PSR), so I tried enabling it with Linux, but got the flickering screen other users report as well when enabling PSR. That seems to be a generic Linux problem, so we can hope that gets solved someday.

[l1k]

Linux doesn't power down the Thunderbolt controllers currently. Each consumes about 2 Watt, that's 4 Watt out the window on models with two controllers.

I have a series to power the controllers down on Linux, I've been using it on my machine for more than a year now. I've slowly been upstreaming all the prerequisites and am currently stuck with upstreaming a series to runtime suspend PCIe ports. It will take a while until all the necessary bits have landed.

That said, my series hasn't been updated for Alpine Ridge yet, there are some changes needed but finding out exactly what needs to be changed will require someone with TB3 and USB-C devices and some time to experiment.

[roadrunner2]

@l1k Looking forward to these making it upstream. (Update: I somehow managed to miss your last paragraph, so my previous comments here were highly redundant and have been deleted now).

[puellanivis]

The whole reason linux started telling DSDT that it was Mac OSX was so that it kept the Thunderbolt powered up.

I find it frustrating that so many of the problems for the MBP 13,x are solved by making the DSDT reject an OSX code path, when the only reason it's there is because some people use Thunderbolt. What if one doesn't?

There really ought to be a command-line switch to turn this “tell DSDT it's OSX” option off…

[l1k]

The command line switch you're looking for is acpi_osi=!Darwin, see Documentation/acpi/osi.txt in the kernel source tree.

On Macs older than 2015, this causes the Thunderbolt controller to be powered down permanently because Apple didn't bother to support Thunderbolt on Windows, so they just made it disappear. On 2015+ Macs they added Thunderbolt support for Windows, which is not surprising given newer MacBook Pros don't have any other ports. Thus my expectation is that this command line switch will not cause the Thunderbolt controllers to be powered down on the MacBookPro13. (But it may be worth a try.)

[l1k]

@roadrunner2: The TRPE method to power the controller up and down is still there. But there is no XRIN method to determine the GPE used as wake interrupt. I just took a look at the 10.12.5 AppleThunderboltNHI.kext and for Thunderbolt 3 they're using a "notification based runtime power management" instead of "GPE based". Whatever that means. Looking at some Alpine Ridge documents I've noticed that the POC_GPIO_4 pin, which is used to signal wakeup, is apparently connected to the WAKE# pin of the PCIe socket. Which seems to indicate they've given up on their custom scheme and switched to the standardized WAKE# method as per the PCIe spec. I'm not an expert on this but I think it means the controller powers itself up automatically on hotplug, then signals to the root port that it's woken. This should result in a PME being generated and we've got code to runtime resume the device upon a PME. Hm, I've not got a very good sense yet how this is all supposed to work on Thunderbolt 3, but it's very different from the older machines.

[Dunedan]

Linux doesn't power down the Thunderbolt controllers currently. Each consumes about 2 Watt, that's 4 Watt out the window on models with two controllers.

Might be obvious, but does that, as soon as powering them down properly works, mean that it'd be more energy efficient to run two thunderbolt devices through the ports on one side than one on on each side?

[puellanivis]

I knew about the acpi_osi=!Darwin command-line. It did nothing with regard to fixing the necessity of me changing the DSDT for touchpad/keyboard control… so… I'm just going to assume it doesn't work, because all evidence suggested that it doesn't… (And I haven't updated my kernel from 4.11.3 so… no reason to try anew.

I guess I just don't like “hacks” being introduced as default behavior… but anyways, enough off-topic ranting… sorry to intrude…

[l1k]

@Dunedan:

Might be obvious, but does that, as soon as powering them down properly works, mean that it'd be more energy efficient to run two thunderbolt devices through the ports on one side than one on on each side?

Yes.

BTW Thunderbolt support for the MacBookPro13 has been queued up for 4.13: https://www.spinics.net/lists/kernel/msg2525682.html

This was done by Intel and is going to be different from Thunderbolt support on older Macs. (Tunnels are established by a firmware on the controller rather than the OS; DisplayPort-over-Thunderbolt tunnels are supported which are still missing from our OS driver, etc.)

[Dunedan]

Interesting read, thanks for sharing.

Especially PATCH v4 26/27 is interesting. Some quotes:

Host NVM upgrade on Apple Macs is not supported.

No candy for us 😢

Note OEM-specific method to power the controller up ("force power") may be available for your system in which case there is no need to plug in a Thunderbolt device.

That would match to what @l1k mentioned earlier, as long as Apple is not one of these OEMs.

[peterychuang]

Some observations from MBP14,1:

Since 14,1 doesn't have discrete GPU, touchbar, and whatever, the battery discharge rate is quite a bit lower. The interesting thing is, if I powered on the machine with the AC unplugged, the idle discharge rate at lowest screen brightness and with wifi and bluetooth both on averages at around 5.7W. However, if I powered on the machine with the AC plugged in and then I unplugged the AC later, the lowest discharge rate I can get is about 6.2W. That's almost an hour of idle battery life. The same is true for if I powered on the machine with the AC unplugged, then I plugged and unplugged again, the discharge rate stays at around 6.2W or so.

[roadrunner2]

The reason for that difference is most likely the excessive EC interrupts. If you run grep enabled /sys/firmware/acpi/interrupts/gpe* you'll see that in the higher power use case the gpe07 interrupts are going crazy. This also causes some other minor issues (see e.g. cb22/macbook12-spi-driver#13).

[peterychuang]

@roadrunner2 you are quite right, gpe07 does seem to go a little crazy when that happens.

[peterychuang]

Maybe related: https://bugzilla.kernel.org/show_bug.cgi?id=117481 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9c4aa1eecb48cfac18ed5e3aca9d9ae58fbafc11

I'm testing acpi_mask_gpe=0x07 kernel option at the moment. For now it stops the interrupts, though I'm not sure yet if it affects anything else.

[l1k]

@peterychuang: That bugzilla entry is for GPE 0x06 which is used by the integrated GPU on the 2013/2014 MacBookPro11,2 and 11,3. There's actually a bugzilla entry with more detailed info:

https://bugs.freedesktop.org/show_bug.cgi?id=98501

In any case it's not the same thing as the issue you're seeing with GPE 0x07, apparently the SMC is crying for attention so I suspect the applesmc.c driver needs to be amended to deal with it? Not sure.

[peterychuang]

@l1k You're right, they aren't the same issue. I thought I would just mask it and see how that would go. In any case, it didn't save nearly as much power as I thought it would.

This bit of the dsdt maybe be of interest.

[Dunedan]

Linux doesn't power down the Thunderbolt controllers currently. Each consumes about 2 Watt, that's 4 Watt out the window on models with two controllers.

I have a series to power the controllers down on Linux, I've been using it on my machine for more than a year now. I've slowly been upstreaming all the prerequisites and am currently stuck with upstreaming a series to runtime suspend PCIe ports. It will take a while until all the necessary bits have landed.

@l1k: Do you have an update on that for us? Anything we can help you with?

In any case it's not the same thing as the issue you're seeing with GPE 0x07, apparently the SMC is crying for attention so I suspect the applesmc.c driver needs to be amended to deal with it? Not sure.

Did anybody look further into that gpe07 issue?

[l1k]

Do you have an update on that for us? Anything we can help you with?

I need to rebase and rework the patches, however I've been busy with GPU runtime PM lately (on dual GPU models), I'll get back to Thunderbolt runtime PM afterwards.

[Dunedan]

Today I made an interesting observation: I noticed the CPU package only goes into the C3 (pch3) power mode and not into deeper power saving modes. The individual CPUs do, but not the whole CPU package.

Searching the internet I quickly stumbled about some blog posts and bug reports (e.g. https://mjg59.dreamwidth.org/41713.html) describing the same problem. Long story short: If the storage device isn't properly configured for power saving itself, the CPU package won't switch into deeper power saving modes at all. This seems to apply to SATA devices as well as NVMe devices. For NVMe devices, like we have in the MacBook Pro, the solution usually is to enable APST (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664602). And here is the catch: As already noted in this issue, right now it looks like the NVMe controller in the MacBook Pro's doesn't support APST and we have no other way yet to enable its power saving modes.

That could be the reason for a few watts of additional power usage, but I doubt it could be responsible for 4W.

Given these new insights I think it's now absolutely plausible that the NVMe SSD not using power saving modes is responsible for such high additional power usage, because it's not just the SSD using more power, but the CPU package as well, as it doesn't go into deeper power saving modes.

[peterychuang]

@Dunedan I'm curious: does your machine still consume 9W+ on idle?

[Dunedan]

Nowadays I'm able to get down to ~7W. Doesn't really help though, as that's with e.g. the display backlight at its minimum, so it's no setup one can work with.

[roadrunner2]

FYI: on my MBP13,3, with the dGPU disabled (via switcheroo), I see about 8.7W - 9W usage with the display off, or about 12W at 50% brightness.

I also see that the CPU package never goes below c3 state (according to powertop); however, in my case this isn't related to APST not being enabled for the NVMe driver:

# sudo nvme get-feature -f 0x0c -H /dev/nvme0n1
get-feature:0xc (Autonomous Power State Transition), Current value:0x000001
    Autonomous Power State Transition Enable (APSTE): Enabled
    Auto PST Entries    .................
    Entry[ 0]   
    .................
    Idle Time Prior to Transition (ITPT): 71 ms
    Idle Transition Power State   (ITPS): 1
    .................
    Entry[ 1]   
    .................
    Idle Time Prior to Transition (ITPT): 360 ms
    Idle Transition Power State   (ITPS): 2
    .................
        [snip]

So at least for this system something else must be preventing the deeper sleep states.

Btw., the controller is a SM961/PM961:

# lspci | grep NVMe
02:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961

So maybe Apple fixed something here, as this doesn't suffer from the hang/reset issue reported in the above Ubuntu bug.

[rwuwon]

Battery usage while mostly idle has been better than I expected since clean installing to an external SSD (Crucial MX500 250GB via a cheap M.2 to USB 3.0 enclosure) on a MBP 13,1 (which has a slightly larger battery than TB models) running 4.16.16-300.fc28.x86_64:

Using GNOME (Wayland) and not much other than htop running, display set to not dim or turn off, I got around 2h 20m from 100% to 70% (estimated: 7h 45m, or about 7W).

With i3wm and not much other than htop running, display a little brighter but auto sleeping occasionally (because I haven't yet tweaked the settings under X11): about 2h 30m from 100% to 70% (estimated: 8h 20m / 6.5W).

Brightness for both set to the lower end (lowest notch with GNOME), but still very readable at night.

Browsers and JavaScript aside, this seems pretty good to me. Under macOS 10.13.5 and mostly Safari (which is generally accepted as being the best browser for power consumption) I generally average around 7 hours with "normal" web browsing usage - perhaps 8 if I'm doing more static webpage reading and terminal work. I've never seen 10 hours before on my system, estimated or otherwise; although I haven't tried to play a video on loop for that length of time before either. This battery is about 3 months old with not too many cycles thanks to a top case replacement this year (for a shortened battery life issue; not keyboard).

So, usage right now seems to be better than my previous test setup of booting from a SanDisk Extreme USB 3.0 stick (16GB Z80) which I haven't yet recorded figures for. I picked the SSD based on price/performance/power consumption according to AnandTech reviews.

Do we have any power usage figures comparing the 2015 MBP to the 2016/2017 ones?

[Ninlives]

What's the status now? Have the patches applied to the kernel that power down thunderbolts at runtime merged to upstream?

[l1k]

@Ninlives: Partially. 4.19 contains a massive pciehp rework which is a prerequisite. That took months to implement, I'm emerging only now from that rabbit hole. Mika meanwhile added preliminary thunderbolt runtime PM. That series is only relevant for non-Macs however, and even on those isn't complete yet. Next step is that I'll rebase my patches for thunderbolt runtime PM on Macs on Mika's patches. This might land in 4.20, but only works with TB1+TB2. I'll let you guys know when it's ready so that someone can hack on it and add TB3 support. It's probably not too hard, I just don't know exactly what's necessary because my own machine doesn't have TB3.

[lovesegfault]

@l1k You are a hero, thank you so much for your work!

[Ninlives]

@l1k sincerely thanks for your work!

[roadrunner2]

FYI, I figured out a fix for the excessive GPE interrupts (that were consuming ~ 58% cpu with recent kernels on my laptop) - see my patch on bug 198169.

[Ninlives]

@roadrunner2 My MBP can cool down on idle now, thanks!

[roadrunner2]

@Ninlives Thanks for testing and reporting back.

[Dunedan]

:drum: I figured out what's preventing the CPU package to reach deeper power states: It's just the missing power management for the Thunderbolt controllers. More specifically they need to have ASPM enabled and need to transition into the "D3" PCIe power state.

To reach lower CPU package states with Linux 4.19 you need to:

• disconnect all devices attached to the Thunderbolt controllers
• boot with pcie_aspm=force as kernel parameter
• unload the thunderbolt module
• put the Thunderbolt controllers into the PCIe "D3" power state (I did achieve that by toggling them in powertop or by echo "auto" > /sys/bus/pci/devices/0000:xx:00.0/power/control, although that's not forcing them into a low power state)

After that I get the CPU around ~65% of the time in PC7 and ~20% of the time in PC8 when I have just an idling desktop. With Touch Bar enabled (without timeout and dimming) and display brightness at 50% I get a power usage of ~7W in that case.

So I believe @l1k's Thunderbolt runtime PM patches will not only save energy by putting the Thunderbolt controllers into lower power modes, but also by allowing the CPU package to transition to states lower than PC3.

@l1k: Is enabling ASPM for the Thunderbolt controllers also on your list? I'm not sure how that works, but I guess the driver somehow need enable ASPM.

[l1k]

I figured out what's preventing the CPU package to reach deeper power states: It's just the missing power management for the Thunderbolt controllers. More specifically they need to have ASPM enabled and need to transition into the "D3" PCIe power state.

Makes sense, the Thunderbolt controller is directly attached to the PCIe root complex in the CPU, not to the PCH.

echo "auto" > /sys/bus/pci/devices/0000:xx:00.0/power/control

Right. That should only be necessary for the NHI and perhaps the XHCI. The hotplug ports will runtime suspend automatically from 4.19 onward.

Is enabling ASPM for the Thunderbolt controllers also on your list?

No, so far not, more aggressive ASPM requires the command line parameter you've posted and I'm not sure if this will ever change, I think there are issues with some devices if ASPM is enabled by default.

[l1k]

Oh in case anyone is interested, I wrote an LWN article on the recent PCIe hotplug improvements, including support for runtime power management in 4.19.

[Dunedan]

Thanks for this awesome LWN article @l1k. Very good read. :+1:

As your previous comment regarding ASPM puzzled me, I did a few more tests and it turned out that enabled ASPM isn't even necessary. The proper PCIe power state is sufficient to allow the CPU to reach lower package states.

That enabled ASPM isn't necessary does puzzle me again, because enabling ASPM to reach lower CPU package power states was the explanation for a Realtek related commit, which made it into 4.19. Anyway, I'm happy that it's clear now what's preventing the lower CPU package states, whether it's ASPM or not. :smile:

I'm now eagerly waiting for your runtime PM work and hope we'll get TB3 support for it done soon after. :smiley:

[Dunedan]

A little update regarding Panel-Self-Refresh (PSR): While I encountered flickering when I initially tried it out, with recent kernels enabling isn't even possible anymore. Turns out this is on purpose as PSR got disabled for all Apple devices in the Linux kernel. As usual they need special handling, which isn't implemented in the driver yet: https://github.com/torvalds/linux/commit/7c5c641a930ed06ca317ee39faee7d5824266348