1556558 - Investigate enabling macOS AppNap to save power

Status: NEW

(Core :: Widget: Cocoa, defect, P2)

Description

[Haik Aftandilian [:haik]]

We should investigate enabling AppNap to save power in a way that doesn't cause hangs. See bug 1551990 for more information. The problem with AppNap today is that macOS puts the parent process into the AppNap state, but not child processes. This can cause child processes to generate lots of IPC traffic for the parent when the parent is AppNap'd and can't respond quickly enough.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:spohl, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Stephen A Pohl [:spohl]]

Haik, do you think that after we fix the issue described in bug 1567018 comment 27 we should try re-enabling macOS AppNap here? Or are we aware of other issues that would still cause problems due to child processes not entering AppNap mode?

Comment 3

[Haik Aftandilian [:haik]]

(In reply to Stephen A Pohl [:spohl] from comment #2)

Haik, do you think that after we fix the issue described in bug 1567018 comment 27 we should try re-enabling macOS AppNap here? Or are we aware of other issues that would still cause problems due to child processes not entering AppNap mode?

The issue we hoped to be addressing by disabling AppNap was network requests being queued up when content processes run during PowerNap while the parent is not getting to run. Assuming that's correct, it might be a case of needing to tell child processes to stop network activity (see bug 1567018 comment 4). Doing that in a way that doesn't cause all processes to overload the parent again when they wake up. I need a more definitive understanding of what happens during PowerNap and wakeup with network requests. I was never able to reproduce the networking high CPU load.

If we misdiagnosed the problem and it was the sqlite issue all along, then it would be worth trying.