This is on my X1 Carbon, F35 beta but it was also happening with F34. Wayland. top -b from Firefox followed by Chrome. This is with only a few tabs open and one Google Meet video call. I think this is the same problem we were having with people's audio on Nest. In Firefox in particular, when the load is that high, the audio totally breaks up. Chrome also drives the CPU and load average up but audio stays smooth. In Firefox, I found the advice to change gfx.webrender.all to true, and I thought at first that helped, but it clearly isn't. I tried under X11, and with a clean profile, and load is still high, but maybe not quite as high -- might just be because I didn't have a bunch of heavyweight other tabs open? ---- top - 11:04:03 up 12 days, 19 min, 2 users, load average: 12.10, 6.24, 3.14 Tasks: 443 total, 4 running, 439 sleeping, 0 stopped, 0 zombie %Cpu0 : 71.4/28.6 100[ ] %Cpu1 : 70.4/22.2 93[ ] %Cpu2 : 66.7/23.3 90[ ] %Cpu3 : 70.4/22.2 93[ ] %Cpu4 : 73.1/23.1 96[ ] %Cpu5 : 80.8/15.4 96[ ] %Cpu6 : 71.4/28.6 100[ ] %Cpu7 : 82.8/13.8 97[ ] GiB Mem : 15.4 total, 0.2 free, 9.0 used, 6.2 buff/cache GiB Swap: 8.0 total, 4.5 free, 3.5 used. 2.9 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1092576 mattdm 20 0 9947.5m 926.0m 153.4m R 256.5 5.9 17:01.67 /usr/lib64/firefox/firefox -contentproc -childID 11 -is+ 1091738 mattdm 20 0 7015.5m 874.0m 333.8m R 217.4 5.5 420:28.70 /usr/lib64/firefox/firefox 1091986 mattdm 20 0 15.6g 753.8m 79.3m R 69.6 4.8 200:07.41 /usr/lib64/firefox/firefox -contentproc -childID 6 -isF+ 428142 mattdm 20 0 6585.8m 414.3m 213.0m S 30.4 2.6 228:51.23 /usr/bin/gnome-shell 1091846 mattdm 20 0 213.2m 27.3m 24.0m S 17.4 0.2 18:06.09 /usr/lib64/firefox/firefox -contentproc -parentBuildID + ---- top - 11:06:43 up 12 days, 22 min, 2 users, load average: 16.23, 10.20, 5.13 Tasks: 478 total, 10 running, 468 sleeping, 0 stopped, 0 zombie %Cpu0 : 76.6/19.6 96[ ] %Cpu1 : 82.6/14.7 97[ ] %Cpu2 : 80.9/14.5 95[ ] %Cpu3 : 73.8/23.4 97[ ] %Cpu4 : 76.6/19.6 96[ ] %Cpu5 : 77.6/19.6 97[ ] %Cpu6 : 93.6/6.4 100[ ] %Cpu7 : 68.2/27.3 95[ ] GiB Mem : 15.4 total, 0.2 free, 9.3 used, 6.0 buff/cache GiB Swap: 8.0 total, 4.5 free, 3.5 used. 2.5 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1182454 mattdm 20 0 70.8g 405.4m 135.7m R 282.7 2.6 1:40.82 /opt/google/chrome/chrome --type=renderer --enable-c+ 1181925 mattdm 20 0 6.2m 1.4m 1.2m R 93.6 0.0 1:29.73 /usr/libexec/cgroupify app-gnome-google\x2dchrome-11+ 1091738 mattdm 20 0 6417.2m 799.5m 317.4m R 59.1 5.1 423:32.97 /usr/lib64/firefox/firefox 428142 mattdm 20 0 6496.0m 409.7m 203.6m S 40.9 2.6 229:41.68 /usr/bin/gnome-shell 1181981 mattdm 20 0 16.8g 142.1m 99.0m R 38.2 0.9 0:15.39 /opt/google/chrome/chrome --type=gpu-process --field+
Please do: 1) attach your about:support page. 2) check if test webrtc page shows it too (https://bluejeans.com/111/webrtc) 3) test clean profile: https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Test_Firefox_with_a_new_profile 4) test Mozilla binaries: https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Testing_Mozilla_binaries 5) test without Wayland (run firefox-x11 or test Mozilla binaries without MOZ_ENABLE_WAYLAND) Also is that a recent regression? Did it work properly in a previous FF version?
I don't need it now but it will be also interesting to see info from performance tools: https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Firefox_performance_issues
@Martin I will provide that information shortly. Thanks! It isn't a regression with the current version; it has been happening for some time. But, it wasn't _always_ happening. I can't, unfortunately, pinpoint when.
If you see that with Firefox & Chrome I expect it's something system-wide. Please try to get the performance data: https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Firefox_performance_issues especially the profiler may help here. Also can you try to do the video call without camera and/or without mike to see if it helps?
1. Profile attached. 2. Test webrtc is high, but maybe not quite as high? ``` Tasks: 402 total, 1 running, 401 sleeping, 0 stopped, 0 zombie %Cpu0 : 17.6/5.9 24[ ] %Cpu1 : 5.9/5.9 12[ ] %Cpu2 : 12.5/0.0 12[ ] %Cpu3 : 16.7/11.1 28[ ] %Cpu4 : 12.5/6.2 19[ ] %Cpu5 : 11.8/11.8 24[ ] %Cpu6 : 11.1/11.1 22[ ] %Cpu7 : 5.9/5.9 12[ ] GiB Mem : 15.4 total, 7.2 free, 3.9 used, 4.3 buff/cache GiB Swap: 8.0 total, 6.4 free, 1.6 used. 8.9 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 79776 mattdm 20 0 4493.8m 669.9m 336.0m S 43.8 4.2 21:08.20 /usr/lib64/firefox/firefox 82057 mattdm 20 0 2964.2m 296.3m 127.1m S 43.8 1.9 1:01.09 /usr/lib64/firefox/firefox -contentproc -childID 16 -isForBrowser -prefsLen 10530 -prefMapSize 2+ 2372 mattdm 20 0 6264.7m 305.0m 156.9m S 12.5 1.9 36:30.25 /usr/bin/gnome-shell 5352 mattdm 20 0 852.4m 99.1m 69.3m S 6.2 0.6 1:45.70 /usr/libexec/gnome-terminal-server 82696 root 0 -20 0.0m 0.0m 0.0m I 6.2 0.0 0:00.30 [kworker/u17:4-uvcvideo] 1 root 20 0 172.5m 10.4m 6.2m S 0.0 0.1 0:04.84 /usr/lib/systemd/systemd rhgb --switched-root --system --deserialize 31 2 root 20 0 0.0m 0.0m 0.0m S 0.0 0.0 0:00.19 [kthreadd] ``` 3. Above is with a new profile. Here's with Google Meet running in that profile: op - 14:21:36 up 1 day, 4:17, 2 users, load average: 3.22, 2.27, 1.91 Tasks: 393 total, 1 running, 392 sleeping, 0 stopped, 0 zombie %Cpu0 : 17.6/5.9 24[ ] %Cpu1 : 29.4/11.8 41[ ] %Cpu2 : 12.5/0.0 12[ ] %Cpu3 : 17.6/5.9 24[ ] %Cpu4 : 5.9/5.9 12[ ] %Cpu5 : 17.6/5.9 24[ ] %Cpu6 : 12.5/0.0 12[ ] %Cpu7 : 5.6/11.1 17[ ] GiB Mem : 15.4 total, 8.1 free, 4.0 used, 3.3 buff/cache GiB Swap: 8.0 total, 5.3 free, 2.7 used. 9.5 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 80416 mattdm 20 0 9421.4m 457.4m 161.0m S 75.0 2.9 13:58.65 /usr/lib64/firefox/firefox -contentproc -child+ 79776 mattdm 20 0 4502.2m 657.3m 325.9m S 37.5 4.2 18:53.90 /usr/lib64/firefox/firefox 2372 mattdm 20 0 6252.5m 247.7m 148.5m S 12.5 1.6 35:38.89 /usr/bin/gnome-shell 5352 mattdm 20 0 845.1m 91.6m 64.2m S 12.5 0.6 1:36.97 /usr/libexec/gnome-terminal-server 80229 mattdm 20 0 213.2m 48.6m 39.3m S 6.2 0.3 3:43.69 /usr/lib64/firefox/firefox -contentproc -paren+ 82218 mattdm 20 0 220.9m 4.3m 3.5m R 6.2 0.0 0:00.01 top -b 1 root 20 0 172.5m 10.1m 6.0m S 0.0 0.1 0:04.38 /usr/lib/systemd/systemd rhgb --switched-root + 2 root 20 0 0.0m 0.0m 0.0m S 0.0 0.0 0:00.18 [kthreadd] This is lower than the numbers I was seeing before, but I think maybe if I let it go longer it'd go up. 4-5: I'll test the Mozilla binaries and without Wayland next (although I did previously run in X11 session to see if that would help, and it didn't). I think this _is_ a regression, but it's been this way for at least six months.
The %CPU numbers looks reasonable to me (at least I see similar values). I wonder if you see better values when you disable camera (don't encode/send video) and/or disable mike. It's possible that Google Meets works worse on Firefox as Google penalizes non-Chrome browsers on its sites or it uses bigger camera resolution (CPU load depends on your camera resolution).
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.