Summary: | www/firefox 104: high CPU usage | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Riccardo Torrini <riccardo> | ||||||
Component: | Individual Port(s) | Assignee: | freebsd-ports-bugs (Nobody) <ports-bugs> | ||||||
Status: | Open --- | ||||||||
Severity: | Affects Some People | CC: | eduardo, fernape, gecko, grahamperrin, madpilot | ||||||
Priority: | --- | Keywords: | performance | ||||||
Version: | Latest | Flags: | fernape:
maintainer-feedback?
(gecko) |
||||||
Hardware: | amd64 | ||||||||
OS: | Any | ||||||||
See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263436 | ||||||||
Attachments: |
|
Description
Riccardo Torrini
2022-09-06 20:38:47 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. 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). 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. Created attachment 236423 [details]
pkg prime-origins | sort (requested by Graham Perrin)
(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? (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 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? 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 :-( 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 :-( How are things with 112.0.1_1,2 (and other packages from latest) on 13.2-RELEASE? (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 ;) |