Bug 266259 - www/firefox 104: high CPU usage
Summary: www/firefox 104: high CPU usage
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2022-09-06 20:38 UTC by Riccardo Torrini
Modified: 2023-04-26 19:50 UTC (History)
5 users (show)

See Also:
fernape: maintainer-feedback? (gecko)


Attachments
Screenshot: Firefox from quarterly on FreeBSD 13.1-RELEASE-p2 in VirtualBox (74.35 KB, image/png)
2022-09-07 02:41 UTC, Graham Perrin
no flags Details
pkg prime-origins | sort (requested by Graham Perrin) (1.62 KB, text/plain)
2022-09-07 20:09 UTC, Riccardo Torrini
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Riccardo Torrini 2022-09-06 20:38:47 UTC
After updating www/firefox from 103.0.1 to 104.0_2 (also to 104.0_3 and 104.0.1), I noticed the CPU at 100% with top showing 300+% on the first Firefox process.

This with 103:
CPU:  0.4% user,  0.0% nice,  1.0% system,  0.1% interrupt, 98.5% idle
Mem: 3077M Active, 5510M Inact, 223M Laundry, 1606M Wired, 1080M Buf, 5328M Free
Swap: 4273M Total, 4273M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
 1632 riccardo    170  20    0    14G  2478M select   0  17:49   0.30% firefox
[...and 30 more lines with 0.01% or less...]

This with 104:
2361 riccardo    147  25    0    13G  1279M select   0   6:13 334.54% firefox

Also tried with a clean profile (using refresh from within Firefox, removing the entire .mozilla/firefox directory and also with a different user). Returning to 103 stops this problem.

I have many windows open/iconized, with many tabs. And I usually have /home on NFS. I know it. It's bad behavior, even with lockd and statd. But I also tried with a local /home on SSD. Same high CPU usage. Forever (at least for a couple of hours after starting Firefox). No ZFS, only UFS2 both local and remote.

Other tests:
- madpilot@ compiled a 104.0.1 without LTO, same high CPU usage
- madpilot@ saw it on VM under bhyve

Firefox configurations: started 103.0.1/104.0.1 with/without:
- "Use recommended performance settings"
- "Use hardware acceleration when available"
The 103 is still usable, the 104 is not.

Home desktop:
- 13.1-RELEASE-p2 GENERIC amd64
- CPU: Intel(R) Core(TM) i5-7600 CPU @ 3.50GHz (3500.00-MHz K8-class CPU)
- 16GB of RAM
- video: intel: Driver for Intel(R) HD Graphics
- all others pkg updated to latest (all but firefox)
Comment 1 Graham Perrin freebsd_committer freebsd_triage 2022-09-07 01:38:49 UTC
Interesting. 

I have not found this with any recent Firefox on CURRENT, I'm a relatively heavy user (848 tabs at the time of writing, typically across two or more windows with Simple Tab Groups and dozens of other extensions). AMD Thames [Radeon HD 7550M/7570M/7650M] in a circa 2013 notebook with HDD plus old USB flash drives for L2ARC, <https://bsd-hardware.info/?probe=7c6751649b>. 

% zgrep firefox\ upgraded /var/log/messages.0.bz2
Aug 27 17:06:39 mowa219-gjp4-8570p-freebsd pkg[4094]: firefox upgraded: 103.0.2,2 -> 104.0_2,2 
Aug 30 01:03:36 mowa219-gjp4-8570p-freebsd pkg[62139]: firefox upgraded: 104.0_2,2 -> 104.0_3,2 
Sep  1 17:03:28 mowa219-gjp4-8570p-freebsd pkg[43080]: firefox upgraded: 104.0_3,2 -> 104.0.1,2 
% grep firefox\ upgraded /var/log/messages
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #20 main-n257645-160a2f2cdda8: Mon Aug 29 00:44:34 BST 2022     grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400066 1400066
% pkg -vv | grep -e url -e enabled -e priority
    url             : "pkg+http://pkg0.pkt.freebsd.org/FreeBSD:14:amd64/latest",
    enabled         : yes,
    priority        : 2,
    url             : "https://alpha.pkgbase.live/current/FreeBSD:14:amd64/latest",
    enabled         : no,
    priority        : 0,
    url             : "file:///usr/local/poudriere/data/packages/main-default",
    enabled         : yes,
    priority        : 3
% 


(In reply to Riccardo Torrini from comment #0)

> - madpilot@ compiled a 104.0.1 without LTO, same high CPU usage
> - madpilot@ saw it on VM under bhyve

Noted. 


> - all others pkg updated to latest (all but firefox)

Packages from latest, or quarterly? 

pkg lock -l

pkg prime-origins | sort

(Attach as a .txt file, if you like.)


> - video: intel: Driver for Intel(R) HD Graphics

Maybe try graphics/drm-510-kmod

<https://www.freshports.org/graphics/drm-510-kmod/#packages> not yet packaged for quarterly, a run of poudriere completed a few hours ago <http://beefy14.nyi.freebsd.org/build.html?mastername=131amd64-quarterly&build=8327a5f1bca6> so there might be not long to wait. In the meantime we can build from source.
Comment 2 Graham Perrin freebsd_committer freebsd_triage 2022-09-07 02:41:47 UTC
Created attachment 236408 [details]
Screenshot: Firefox from quarterly on FreeBSD 13.1-RELEASE-p2 in VirtualBox

(In reply to Riccardo Torrini from comment #0)

> - madpilot@ saw it on VM under bhyve

Here, with VirtualBox: no problem with a fresh installation of Firefox from quarterly. 

Two packages were slightly outdated at the time of the screenshot, 

Installed packages to be UPGRADED:
	curl: 7.84.0 -> 7.85.0
	sqlite3: 3.38.5,1 -> 3.39.2,1

-- no problem following an upgrade (the subsequent run of Firefox was busy for a short while, soon settled down to less than 1% CPU).
Comment 3 Guido Falsi freebsd_committer freebsd_triage 2022-09-07 07:50:01 UTC
Hi,

I'll explain what I'm seeing.

On my main PC I'm running head and package built with poudriere from head. Firefox is perfectly usable here, except some CPU usage peaks on certain interactions, but these could be caused by a lot of things. These peaks were less frequent a few weeks ago, but again could be unrelated.

The firefox package I build has LTO disabled, but a quick test shows it makes no difference.

In BHyve VMs (13.1, quarterly packages, 2 vCPUs) I noticed firefox being definitely slower at startup and in navigation, with long lasting peaks of CPU usage at every interaction. Also there are firefox processes constantly eating 10-20% CPU even when on a static page doing nothing. This is happening any way firefox is run (via X11 connection to host, RDP, VNC console)

Resetting the firefox profile in the VM (by `rm -rf ~/.mozilla) the issue is mitigated, but is not going away. CPU peaks last a little less, but I still see firefox processes eating CPU when idle.

Moving the machine to latest packages did "fix" the issue.

Firefox anyway IS more jumpy on CPU usage recently, but again, this could be normal behaviour.

Maybe the issue builds up with usage, with firefox profile files growing. Maybe it's not firefox but some other dependency, or something specific happening in the profile, or some firefox port option...Or a combination.
Comment 4 Riccardo Torrini 2022-09-07 20:09:27 UTC
Created attachment 236423 [details]
pkg prime-origins | sort (requested by Graham Perrin)
Comment 5 Riccardo Torrini 2022-09-07 20:16:25 UTC
(In reply to Graham Perrin from comment #1)

> Interesting.

I'm aware that mine is not a gaming machine but up to 103 Firefox was usable (for example fluid demo[1] is enough fluid with 103 and really perfect with chromium-104.0.5112.101, launched now with Firefox opened, on same machine with integrated Intel graphics)

[1] https://paveldogreat.github.io/WebGL-Fluid-Simulation/


> I'm a relatively heavy user (848 tabs at the time of writing)

Around 15 windows with 10-20 tab each, only uBlock Origin and Violentmonkey.


% pkg -vv | grep -e url -e enabled -e priority
    url             : "pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/latest",
    enabled         : yes,
    priority        : 0,


> Packages from latest, or quarterly?

Latest.
% more /usr/local/etc/pkg/repos/FreeBSD.conf 
FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest"
}


% pkg lock -l
Currently locked packages:
gq-1.3.4_14,1
pclock-0.13.1_4
sane-frontends-1.0.14_10
seamonkey-2.49.4_19
wmeyes-1.2_1
(using wmaker and wdm, can't live without wmeyes ;-)


> pkg prime-origins | sort
> (Attach as a .txt file, if you like.)

Added on previous comment.


> Maybe try graphics/drm-510-kmod

from Makefile (I also have a ports tree on home server):
.elif ${OSVERSION} >= 1300136 && ${OSVERSION} < 1400000
RUN_DEPENDS=    ${KMODDIR}/drm.ko:graphics/drm-fbsd13-kmod
.elif ${OSVERSION} >= 1400000
RUN_DEPENDS=    ${KMODDIR}/drm.ko:graphics/drm-510-kmod

I'm 13.1-p2, do I need a pkg add?
Comment 6 Graham Perrin freebsd_committer freebsd_triage 2022-09-08 20:25:15 UTC
(In reply to Guido Falsi from comment #3)

> ... rm -rf ~/.mozilla ...

Side note: you might find some debris in 

~/.cache/mozilla/firefox/

See about:profiles
Comment 7 Riccardo Torrini 2022-09-21 20:50:28 UTC
Some step into the right direction !!

About an hour ago I ran pkg update/upgrade:
- drm-fbsd13-kmod-5.4.191.g20220604_1 deinstalled
- drm-510-kmod-5.10.113_6 installed
- firefox upgraded: 103.0.1,2 -> 105.0_1,2
(reboot)

Not perfect as with 103 or lower but much better.
- CPU remain to 20-25% (never lower than this)
- first firefox process eat 50-70% of CPU (instead of 300+% as before)
- WebGL-Fluid-Simulation is responsive
- chrome perform much better than firefox :-(

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
 1281 riccardo    144  22    0    13G  1549M select   2  33:20  55.86% firefox
 1201 root          8  22    0   481M   265M select   3   1:43   3.27% Xorg
 1322 riccardo     20  20    0  2678M   372M select   3   0:16   0.29% firefox
 1320 riccardo      3  20    0   545M   220M select   0   6:54   0.00% firefox
 1291 riccardo     21  20    0    19G   275M select   0   0:10   0.00% firefox
[...]

Maybe a mix of fix on drm-510 and firefox-105.
How can I help any further?
Comment 8 Riccardo Torrini 2022-10-28 19:56:52 UTC
Bad news:
- latest version of chrome and firefox breaks grafana (maybe something related to drm or video drivers?). It happens either on intel than on nvidia Quadro K5000 (but not on Quadro 2000). Upgraded from 390 to 470 on K5000, no difference.

Some more info:
- reinstalled all pkg (with upgrade -f, hint from mad@, no difference)
- tried a lot of version of firefox (and chrome), from 100 to 106

After a lot of tests (all with clean ff/chrome profile) I found that chromium-103.0.5060.53 is able to show grafana graphs (on my system at least).

No way with firefox, from 100 to 106 :-(
Comment 9 Riccardo Torrini 2022-10-30 22:18:46 UTC
Used some hints from here:
https://wiki.archlinux.org/title/intel_graphics#DRI3_issues

This is my current xorg.conf (very minimalistic):
Section "Device"
        Identifier  "Device0"
        Driver      "intel"
EndSection

Added some options:
- "dri" "3"
- "AccelMethod" "sna"
- "TearFree" "true"
- "TripleBuffer" "true"
but no differences.

Changed driver from "intel" to "modesetting":
[  4874.032] (II) Initializing extension DRI2
[  5857.446] (II) Initializing extension DRI3
[  5857.448] (II) AIGLX: Screen 0 is not DRI2 capable
running /usr/local/bin/xscreensaver-hacks/glhanoi fullscreen I got ~30 fps

Back to intel:
[  6117.810] (II) intel(0): [DRI2] Setup complete
[  6117.810] (II) intel(0): [DRI2]   DRI driver: iris
[  6117.810] (II) intel(0): [DRI2]   VDPAU driver: va_gl
[  6117.810] (II) intel(0): DRI2: Enabled
[  6117.810] (II) intel(0): DRI3: Disabled
[  6117.849] (II) Initializing extension DRI3
[  6117.882] (II) GLX: Initialized DRI2 GL provider for screen 0
[  6117.882] (II) Initializing extension DRI2
running /usr/local/bin/xscreensaver-hacks/glhanoi fullscreen I got ~54 fps

I also noticed a random screen freeze (several seconds) not only using Firefox but also changing focus on xterm (or typing this message)

From dmesg.boot:
drmn0: <drmn> on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
[drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19).
[drm] Got stolen memory base rxc4000000, size 0x4000000
drmn0: successfully loaded firmware image 'i915/kbl_dmc_ver1_04.bin'
drmn0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
[drm] Initialized i915 1.6.0 20200917 for drmn0 on minor 0

Grafana still not working on firefox (on any test)

What should be the "right" X.org configuration for an i5-7600 (KabyLake)?
I'm not sure that all problems are from firefox, maybe some drm issue.
I'm really out of ideas for more test :-(
Comment 10 Graham Perrin freebsd_committer freebsd_triage 2023-04-23 11:54:53 UTC
How are things with 112.0.1_1,2 (and other packages from latest) on 13.2-RELEASE?
Comment 11 Riccardo Torrini 2023-04-26 19:50:02 UTC
(In reply to Graham Perrin from comment #10)

Still on 13.1-p3 and firefox 111 :-(
Anyway, after a lot of update related to intel graphics, is seem more fluid. But I'm not able to give you a date where it started to works better.
I'm hoping to have time to upgrade to 13.2 this weekend.

ps: now cpu is at 16-20%, not the best but much better ;)