1832883 - Nightly is spinning when switching tabs with Mac under high load

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Mark Banner (:standard8)]

A few times today, I've had this issue. Not sure if it is only on the latest nightly, but I haven't seen it for a while.

I'm on a 2021 M1 Max MacBook Pro.

STR

1. Start a full build of Firefox or Thunderbird from mozilla-central.
2. During the intense parts (dom/ ?), try switching tabs in Firefox.

Expected Results

Tab switch to happen straight away.

Actual Results

The tab hangs, potentially for a long time, until the load lightens. If the build is stopped, it generally clears straight away.

Here is a profile exhibiting the behaviour:

https://share.firefox.dev/3O5jt27

The first place where the spinner cleared, it cleared itself I think the load was slightly lessened.

The last place I manually killed the separate build.

Comment 1

[Mark Banner (:standard8)]

Running mozregression gives me:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3b6c50f1f85c33a9ecaef51992893b6d5ea202ff&tochange=f9836204ac87c171b1a17d321288358680019a5a

which is bug 1832365.

Toggling the threads.lower_mainthread_priority_in_background.enabled preference off also fixes it for me.

Whilst testing under high loads, I noticed a couple more things:

• I once had the "<tab> is causing your browser to be slow, would you like to stop it" notification pop up.
• Shutting down Firefox was also slow.

Comment 2

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1832365

Comment 3

[Kris Wright :KrisWright]

This is the sort of performance regression expected (but not desired) from this change. I am able to reproduce this on my machine by writing a quick program that forces all cores to spin. I think we can fix this by getting a boilerplate CPU utilization metric from the system and avoiding exercising the new codepaths in the event of high utilization. I'll see if I can get a fix up shortly.

Comment 4

[Kris Wright :KrisWright]

To add some notes from some discussion about the issue: QOS class cannot be set off of the owning thread; while we can set the thread attributes for startup, we cannot realistically set the actual QoS class offthread. Therefore we cannot realistically use cpu utilization as a metric to "warm up" the main thread, because the deprioritized main thread cannot be woken up by anything but itself. Instead we will experiment with adjusting the priority we are using.

Comment 5

[Kris Wright :KrisWright]

Attachment: Bug 1832883 - Raise priority of background mainthreads to Utility level r?#xpcom-reviewers

Utility level is often used for nonperceivable work, but operates at a higher level than a background priority. This puts our background main thread priorities on the same level as the OS uses for general offthread work, so the perceivable delay to warm up the main thread on high cpu usage is limited to a few seconds (previously indefinite).

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7499fc1efcd5
Raise priority of background mainthreads to Utility level r=xpcom-reviewers,nika

Comment 7

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/7499fc1efcd5