1531756 - Firefox idles 1-15% CPU on about:blank on fresh Arch install (wayland)

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect, P3)

Description

[Kenny Levinsen :kennylevinsen]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

1. Install Arch base (minimal, interference-free environment)
2. Install Weston or sway (minimal, interference-free wayland compositor)
3. install firefox-stable, firefox-nightly
4. Start weston or sway
5. Start firefox, firefox-nightly or firefox-nightly with webrender, using an empty profile in safe-mode
6. Go to about:blank to minimize activity
7. Observe activity

The symptoms are easily reproducible using a fresh system.

Actual results:

Laptop using sway (idle i7-8550U):

Everything is very spikey, but settles on the following observed idle ranges:

• Stable: 0.7-5%
• Nightly: 5-10%
• Nightly with webrender: 10-20%

Attempts with Sway and putting firefox on an inactive workspace (which results in no wayland rendering events being sent) did not affect CPU consumption.

The result of this is a very high battery drain.

VM on my server using both weston and sway (mostly idle host exposing all 8 cores of an i7-9700K):

This setup was tested to ensure that the environment has no interference and only contained what was necessary to paint firefox on the screen. Note that the CPU consumption is lower due to the significantly larger capacity of this machine.

Everything is very spikey, but settles on the following observed idle ranges:

• Stable: 0.7-1.3%
• Nightly: 1.3-4%
• Nightly with webrender: 0.7-4%

Only very, very rarely is 0% CPU observed.

Expected results:

0% with occasional small spikes.

Comment 1

[Kenny Levinsen :kennylevinsen]

Attachment: Flamegraph of unoptimized build

Flamegraph recorded for a freshly build, unoptimized firefox with attached.

Firefox was started, on an empty-but-previously-created profile, navigated to about:blank, put on an inactive workspace (sway + wayland), and left running for half a minute until it settled down. Then perf record --call-graph dwarf --pid 7211 --tid 7211,7519,7485,7279 was run for ~20 seconds. At the time of recording, the firefox parent process was consuming 15% CPU.

Not sure I got the options for perf right. Please advise if that's the case. I'm quite interested in figuring out what Firefox is up to when it shouldn't really do anything.

Comment 2

[Kenny Levinsen :kennylevinsen]

Attachment: Flamegraph of unoptimized build

Fixed the flamegraph, recording did not catch all threads.

Comment 3

[Kenny Levinsen :kennylevinsen]

Attachment: Flamegraph of compositor thread

Attached a compositor flame-graph.

Compositor and render threads are responsible for a few CPU percent each on idle. Compositor and Renderer threads look the same, so I only attached the former.

This is due to mozilla::widget::WaylandDisplayLoop, which dispatches the wayland display queue non-blocking at a high rate (see https://bugzilla.mozilla.org/show_bug.cgi?id=1467127). This explains why this I do not observe the consumption under X11. I believe the only correct solution here is to dispatch blocking on a dedicated thread. This allows both maximum responsivity as well as minimum CPU usage.

However, an interesting thing to note is that there also appears to be a lot of allocation going on as part of that loop, making up for a large part of the CPU time. I wonder what is the responsible party—The NewRunnableFunction's allocated, perhaps? It will of course be less of a problem when the rate is reduced, but it would be something worth looking into.

Comment 4

[Kenny Levinsen :kennylevinsen]

Other observations apart from compositor/renderer event dispatch and suboptimal vsync:

1. BHMgr Monitor burns 1-2%. That's a lot for a hang monitor. I wonder if something is causing it to run faster than the 2s interval.
2. Chrome_ChildThread is also around 1-2%. I suspect this is the thread for PBackground? Awfully busy.
3. Gecko_IOThread is around 1%.
4. IPDL background is also occasionally spiking up to 1%.
5. The main thread of firefox and its content processes are responsible for the rest. A flamegraph of a content process was a bit confusing, but it seemed to signal significant time spent in webextension stuff, despite being an empty profile.

Comment 5

[Kenny Levinsen :kennylevinsen]

Attachment: Flamegraph of SoftwareVsyncThread

Also an interesting point: It appears that feeding the global vsync source to the various process is quite expensive. I see quite high peaks from the global vsync thread. On my laptop, it easily spikes to 2%.

I traced a SoftwareVsyncSource here for reference, which is in reality just a glorified for(;;) { notify(); usleep(n); }. A very significant amount of time is spent in DoDelayedWork (which is just sending the event), as well as in AutoProfilerThreadSleep.

Comment 6

[Laurențiu Nicola]

Just to make sure, are you testing with MOZ_ENABLE_WAYLAND=1?

I'm asking because I'm using Wayland with Gnome Shell and I noticed Firefox using ~10% CPU when doing nothing (I just tried it now with an empty profile and a single tab with about:blank loaded manually). MOZ_ENABLE_WAYLAND=1 makes no difference in my case.

Comment 7

[Kenny Levinsen :kennylevinsen]

Yes, I am testing with MOZ_ENABLE_WAYLAND=1.

Try to unset the MOZ_ENABLE_WAYLAND variable instead of setting it to 0 if you want to try under x11. You can also force x11 with GDK_BACKEND=x11. You should see lower utilization, as a good chunk of the problem is in Firefox's wayland handling.

Comment 8

[Laurențiu Nicola]

(In reply to Kenny Levinsen from comment #7)

Yes, I am testing with MOZ_ENABLE_WAYLAND=1.

Try to unset the MOZ_ENABLE_WAYLAND variable instead of setting it to 0 if you want to try under x11. You can also force x11 with GDK_BACKEND=x11. You should see lower utilization, as a good chunk of the problem is in Firefox's wayland handling.

I haven't tried an X11 session (I'm using XWayland), but for me the idle CPU usage is about the same (~10%) regardless of MOZ_ENABLE_WAYLAND. Might be a different issue, then.

Comment 9

[Robert Mader [:rmader]]

Just to add some context:

• Xwayland simulates vsyncs, usually hardcoded 60Hz for visible windows and 1Hz for invisible ones (see https://gitlab.freedesktop.org/xorg/xserver/issues/631#note_110386 for some issues around that). I don't now whether Firefox on X11 repaints on every vsync, but if so the result should be similar in an X11 session and Wayland for visible windows. FF over Xwayland should have lower cpu usage on the inactive workspace though.
• Webrender is currently particular bad at saving power but they plan to make use of more Wayland features to tackle this: https://github.com/servo/webrender/issues/3115

Comment 10

[Kenny Levinsen :kennylevinsen]

Another interesting issue: nsRefreshDrivers are failing to disable their timer.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Assuming the remaining work is Wayland-specific, the right component for this is Widget: GTK, not Graphics.

Comment 12

[Matthew Thode]

iirc the egl swap interval of 0 could be causing some of this as well.

Comment 13

[Robert Mader [:rmader]]

Is this still valid or has it gotten better? Concerning the frame callbacks I also just opened bug 1629140

Comment 14

[Kenny Levinsen :kennylevinsen]

The case for an empty page (about:blank) has gotten a lot better: After waiting a while for things to settle down, I can actually see 0% CPU utilization for short periods of time. It never got there before.

Of course, CPU utilization for various types of basic interaction is pretty absurd (moving a cursor over this bugzilla page is around ~60% CPU utilization for me!), but let's take that in other issues.

(As usual, it is not within my ability to resolve an issue with any sensible status, so I'll have to leave that up to someone else.)

Comment 15

[Emilio Cobos Álvarez (:emilio)]

You should get editbugs access Kenny :-)

I guess this should be WFM pending other improvements.