1995638 - Experiment with changing the default thread quality-of-service on macOS

Status: RESOLVED FIXED

(Core :: XPCOM, task)

Description

[Markus Stange [:mstange]]

We have lots of reports from users about Firefox being generally sluggish on macOS 26 (Tahoe) when the system is busy. It appears that Tahoe is more aggressive about descheduling threads which aren't running work with a defined quality of service.

Here's documentation about how to use quality of service: https://developer.apple.com/library/archive/documentation/Performance/Conceptual/EnergyGuide-iOS/PrioritizeWorkWithQoS.html

We don't really make much use of these APIs at the moment. But we have many threads whose output is needed to complete user-initiated actions.

As a short-term measure, we can try making all nsThreads use "User Initiated" quality of service by default.

Comment 1

[Markus Stange [:mstange]]

Attachment: Bug 1995638 - Make nsThreads use QOS_CLASS_USER_INITIATED by default. r=#xpcom-reviewers

Comment 2

[Markus Stange [:mstange]]

There are a bunch of open questions here, but I think this patch would benefit from immediate testing on Nightly. Jeff convinced me to land it immediately, even without review from XPCOM reviewers.

Bas will add some context about what we saw in the Chromium source code.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/f0c4a4db70b5
https://hg.mozilla.org/integration/autoland/rev/70dde7e1fe92
Make nsThreads use QOS_CLASS_USER_INITIATED by default. r=jrmuizel

Comment 4

[Bas Schouten (:bas.schouten)]

Chromium changes their priority a lot more but generally uses USER_INITIATED as their default priority (see https://source.chromium.org/chromium/chromium/src/+/main:base/threading/platform_thread_apple.mm;l=306).

Changing just the priority of the media thread, as was also an option for fixing one of the issue is unlikely to fix some of the others, which we are struggling to reproduce. We determined that the diagnostically most valuable course of action was landing this. In addition we believe that if this passes tests it is unlikely to cause significant issues on nightly and is most likely to provide us with maximum feedback on any side-effects to a change like this.

Comment 5

[Jens Stutte [:jstutte]]

Note that for nsThreadPool threads this setting will be overridden, not sure if that was the intention.

I'd also assume we could just adjust SetThreadQoS or even add new classes to nsIThread::QoSPriority ? (All this seems to be MacOS only, I wonder if it should be, too?)

Comment 6

[amarc]

https://hg.mozilla.org/mozilla-central/rev/70dde7e1fe92

Comment 7

[Alastor Wu [:alwu]]

(In reply to Jens Stutte [:jstutte] from comment #5)

Note that for nsThreadPool threads this setting will be overridden, not sure if that was the intention.

I'd also assume we could just adjust SetThreadQoS or even add new classes to nsIThread::QoSPriority ? (All this seems to be MacOS only, I wonder if it should be, too?)

Yes, those part of codes are used to set thread QoS to background for lowing the power consumption. My wip patch in bug 1989948 does a similar thing to change nsThread::SetThreadQoS. As what Bas explained in comment 4, we decided to go with the method to change all threads to USER_INITIATED as default, but keep the mechanism to lower background's QoS.

Comment 8

[Jens Stutte [:jstutte]]

Note that for nsThreadPool threads this setting will be overridden, not sure if that was the intention.

I mostly wanted to ensure you are aware of thread pool threads immediately overwriting this setting, IIUC.

Edit: Most likely this if makes this a no-op

Comment 9

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Sluggish browser performance on macOS 26 (Tahoe) on busy machines, video stuttering / pausing
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: On macOS Tahoe (26.0), play a video on YouTube which uses hardware decoding. Then start compiling Firefox, or run a test program which uses all CPU cores. (It's possible that the "stress" program from brew install stress can be used for this but we haven't tried.) Without the fix, the video will pause playing, with the fix it keeps playing.
• Risk associated with taking this patch: medium
• Explanation of risk level: This should land together with https://phabricator.services.mozilla.com/D269786 (from bug 1996052) for minimum risk. The fix is small but the exact effects are hard to reason about. We've confirmed on multiple machines that it fixes the video playback problem and haven't noticed adverse effects yet.

The risk comes from the fact that we now set a specific quality-of-service whereas in the past we were relying on macOS to infer a quality-of-service for us. The inferred QOS might result in a higher or in a lower priority, depending on lots of factors. So the patch can affect CPU scheduling in non-obvious ways, which can affect performance and power usage. Examples where higher-than-before priority would have adverse effects: Background work such as Firefox Sync, updating safebrowsing database, writing out session store JSON etc might now steal more CPU resources from user-interaction-critical tasks. For tabs in the background, work in background threads might now steal more CPU resources from tabs in the foreground. Examples where lower-than-before priority could have adverse effects: Threads which are critical for user interactions, such as the Renderer thread, might now no longer be automatically upgraded to a high priority when they are critical for completing a user interaction (though macOS has mechanisms that we expect would still propagate/override the QOS in many cases, so this may not actually be a real example.)

• String changes made/needed: none
• Is Android affected?: no

Comment 10

[Markus Stange [:mstange]]

Attachment: Bug 1995638 - Make nsThreads use QOS_CLASS_USER_INITIATED by default. r=#xpcom-reviewers

Original Revision: https://phabricator.services.mozilla.com/D269469

Comment 11

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined: Sluggish browser performance on macOS 26 (Tahoe) on busy machines, video stuttering / pausing
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: On macOS Tahoe (26.0), play a video on YouTube which uses hardware decoding. Then start compiling Firefox, or run a test program which uses all CPU cores. (It's possible that the "stress" program from brew install stress can be used for this but we haven't tried.) Without the fix, the video will pause playing, with the fix it keeps playing.
• Risk associated with taking this patch: medium
• Explanation of risk level: This should land together with https://phabricator.services.mozilla.com/D269786 (from bug 1996052) for minimum risk. The fix is small but the exact effects are hard to reason about. We've confirmed on multiple machines that it fixes the video playback problem and haven't noticed adverse effects yet.
• String changes made/needed: none
• Is Android affected?: no

Comment 12

[Markus Stange [:mstange]]

Attachment: Bug 1995638 - Make nsThreads use QOS_CLASS_USER_INITIATED by default. r=#xpcom-reviewers

Original Revision: https://phabricator.services.mozilla.com/D269469

Comment 13

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/ed6b8b09eb27
https://hg.mozilla.org/releases/mozilla-beta/rev/25612dd9ec8e

Comment 14

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/7d719fce4f8f
https://hg.mozilla.org/releases/mozilla-release/rev/037b2f0ae021

Comment 15

[Jeff Muizelaar [:jrmuizel]]

Apple confirmed that they fixed a bug around this and suggested limiting this fix to 26.0 and not doing it in 26.1