Open Bug 1733377 Opened 3 years ago Updated 10 months ago

High CPU usage from main process and Renderer/SwCompositor after a few days of uptime on Nightly/Linux (SW WR and WR, 2x 1440p, Gnome Xwayland AND Wayland, EGL, Fission, drawInTitlebar)

Categories

(Core :: Graphics: WebRender, defect, P3)

Unspecified
Linux
defect

Tracking

()

People

(Reporter: gerard-majax, Unassigned)

References

(Depends on 1 open bug, Blocks 4 open bugs)

Details

(Whiteboard: [not-a-fission-bug])

Attachments

(1 file)

Attached file about:support

Usually takes ~2-3 days of uptime before showing up, main process ~100% of one core, Renderer and SwCompositor each consuming ~80% of one core (so that's 260% in total). Leads to general slowdown on the system.

I took two profiles:

As mentionned on Matrix, while taking the first I cycled two times through two tabs and then I stayed doing nothing ; on the second, I did mostly nothing as well.

From discussion with Alexandre the profile was taken when he wasn't actively interacting with the browser, so there's an expectation that we shouldn't be rendering continuously, however the profile shows that awe are.

There's some activity on the parent main threads as well as content processes at various times, but I also see parts where all main threads are idle and we keep rendering.

According to profile markers, a lot of the frames don't have draw calls nor invalidated picture cache tiles, so we appear to be continuously compositing only.

Blocks: wr-perf

(bug 1733008 is about enabling hardware WebRender for your GPU.)

Blocks: wr-linux
OS: Unspecified → Linux
Summary: High CPU usage from main process and Renderer/SwCompositor after a few days of uptime on Nightly/Linux → High CPU usage from main process and Renderer/SwCompositor after a few days of uptime on Nightly/Linux (SW WR, 2x 1440p, 2nd screen=default, Gnome Xwayland, EGL, Fission, drawInTitlebar)

Why do you set 2nd screen=default ? It's wrong, it's my first enabled screen that is being used. My laptop's screen (#1 in Gnome's numbering) is disabled.

Flags: needinfo?(jan)
Summary: High CPU usage from main process and Renderer/SwCompositor after a few days of uptime on Nightly/Linux (SW WR, 2x 1440p, 2nd screen=default, Gnome Xwayland, EGL, Fission, drawInTitlebar) → High CPU usage from main process and Renderer/SwCompositor after a few days of uptime on Nightly/Linux (SW WR, 2x 1440p, Gnome Xwayland, EGL, Fission, drawInTitlebar)

Filed bug 1733389. Thanks!

Flags: needinfo?(jan)
Blocks: 1690673
No longer blocks: wr-perf
Depends on: 1733405
Whiteboard: [not-a-fission-bug]

Might have happened again, after a few days: https://share.firefox.dev/3aaIl34

  • started after finishing a zoom meeting ? (which I did using nightly, in a different window)
  • I switched from XWayland to Wayland since last time
  • I now have full WebRender enabled on my GPU compared to last time

Looks like bug 1690619 landed, I've updated to buildid 20211006094130, let's see a profile next time it does repro.

Summary: High CPU usage from main process and Renderer/SwCompositor after a few days of uptime on Nightly/Linux (SW WR, 2x 1440p, Gnome Xwayland, EGL, Fission, drawInTitlebar) → High CPU usage from main process and Renderer/SwCompositor after a few days of uptime on Nightly/Linux (SW WR and WR, 2x 1440p, Gnome Xwayland AND Wayland, EGL, Fission, drawInTitlebar)
Blocks: power-usage

Looks like it repro'd: https://share.firefox.dev/3BKmbRk main process ~35-55% CPU, WebRender ~25-30% and gnome-shell taking ~15-20% at the same time (this last one might be unrelated)?

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jmathies)
Severity: -- → N/A
Flags: needinfo?(jmathies)
Priority: -- → P3

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jmathies)

Repro'd? 35% CPU on the main thread, ~10-15% on WebRender/Renderer threads: https://share.firefox.dev/2Z9euq8 (I had to trim some info or upload was failing)

Severity: N/A → S4
Flags: needinfo?(jmathies)
See Also: → 1742842

When this happens (last time was 105.0b5), turning the window manager's compositing off and back on again is enough to reset to a sane state again without renderer/compositor threads running away.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: