Bug 2312900

Summary: kwin_wayland pegging CPU near 100% usage, system very sluggish when using software rendering since KDE 6.2 beta
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: kwinAssignee: Rex Dieter <rdieter>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 41CC: agurenko, jgrulich, kde-sig, lruzicka, rdieter, suraj.ghimire7, than
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: openqa AcceptedFreezeException
Fixed In Version: kwin-6.1.90-3.fc42 kwin-6.2.1.1-1.fc41 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-10-18 21:19:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2247868    

Description Adam Williamson 2024-09-17 18:24:20 UTC 
Since FEDORA-2024-e78c579506 - the KDE 6.2 beta update - landed in Rawhide, the openQA test of Firefox on KDE is failing much more often:

https://openqa.fedoraproject.org/tests/2885008#next_previous

all those failures seem to be because Firefox takes much longer to start up.

The test starts from a base disk image representing a 'normal' KDE install, then sets up a repo containing the package under test and runs a full system update. Then it reboots. It goes to a console and does some Firefox config customizations to try and make Firefox behaviour predictable:

mkdir -p $(rpm --eval %_libdir)/firefox/distribution
printf '{"policies": {"DisableFirefoxStudies": true, "OfferToSaveLogins": false, "OverrideFirstRunPage": "", "OverridePostUpdatePage": ""}}' > $(rpm --eval %_libdir)/firefox/distribution/policies.json
mkdir -p $(rpm --eval %_libdir)/firefox/browser/defaults/preferences
printf "// required comment\npref('general.config.filename', 'openqa-overrides.cfg');\npref('general.config.obscure_value', 0);\n" > $(rpm --eval %_libdir)/firefox/browser/defaults/preferences/openqa-overrides.js
printf "// required comment\npref('browser.urlbar.quicksuggest.shouldShowOnboardingDialog', false);\npref('privacy.restrict3rdpartystorage.rollout.enabledByDefault', false);\n" > $(rpm --eval %_libdir)/firefox/openqa-overrides.cfg

then it launches Firefox by clicking on its launcher icon in the kicker menu. With these config changes, Firefox opens and loads fedoraproject.org/start in the first tab. openQA considers Firefox to be 'running' when it sees the refresh button.

I checked several tests in openQA to see how long this usually takes. On KDE tests *before* the 6.2 update, in one test it took 16 seconds, in another it took 18 seconds. In GNOME tests, it took 11 seconds in both tests I checked. In KDE tests *after* the 6.2 update, in one test I checked it took 49 seconds; in another, it took over 52 seconds (I don't know how much over as the test gave up and switched to a console at that point).

I reproduced this locally, also. I got the 20240914.n.0 (before 6.2) and 20240917.n.0 (after 6.2) KDE live images. For each one, I installed it, booted, did the same openQA config customizations, then clicked the Firefox launcher and started a timer on my phone at the same time. I paused the timer when the refresh button appeared in the Firefox window. For 20240914.n.0 this took 7.9 seconds, for 20240917.n.0 this took 22.1 seconds.

I don't think this is being caused by variations in the server response time, as the results are consistent, and it seems like just getting Firefox started at all - before it's really started connecting to the remote server - takes substantially longer on 6.2, from the openQA videos and my local tests.

The timings may differ if you try to reproduce this. On powerful hardware the difference may be less apparent (e.g. if it's 1 second before but 3 seconds after, that's not super obvious). openQA runs on a powerful host but it runs a lot of VMs simultaneously, so each one isn't *terribly* fast. I did my manual testing on a thin-and-light laptop in a VM with only 2 CPU cores and 4G of RAM allocated, so that's also fairly slow.
Comment 1 Adam Williamson 2024-09-17 18:28:21 UTC 
Huh, looking at 'htop' running in a console on a fresh boot of the 20240917.n.0 ISO after installation, I see two /usr/bin/kwin_wayland processes pegging the CPU at over 90% utilization. I guess that has something to do with it.

Oh, both my test VM and openQA VMs use virtio video.
Comment 2 Adam Williamson 2024-09-17 18:40:03 UTC 
OK, yeah, this is reproducible for me just running the live image on a VM using virtio graphics without 3D acceleration passthrough, and running top. On https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20240914.n.0/compose/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-Rawhide-20240914.n.0.iso I see low CPU usage, on https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20240917.n.0/compose/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-Rawhide-20240917.n.0.iso I see all cores pegged near 100% by kwin.
Comment 3 Adam Williamson 2024-09-17 18:52:10 UTC 
I dumped the journal from both live boots, but nothing obvious leaps out. The 6.2 log has one additional line from kwin:

Sep 17 14:47:43 localhost-live kwin_wayland[2113]: kwin_core: Failed to open drm node: ""

but I think it may just be slightly more verbose logging of the same path, in context. 6.1:

Sep 17 14:44:25 localhost-live kwin_wayland[2126]: kwin_scene_opengl: couldn't find dev node for drm device
Sep 17 14:44:26 localhost-live ksplashqml[2204]: libEGL warning: egl: failed to create dri2 screen
Sep 17 14:44:27 localhost-live kwin_wayland_wrapper[2238]: Refusing to try glamor on llvmpipe
Sep 17 14:44:27 localhost-live kwin_wayland_wrapper[2238]: EGL setup failed, disabling glamor
Sep 17 14:44:27 localhost-live kwin_wayland_wrapper[2238]: Failed to initialize glamor, falling back to sw

6.2:

Sep 17 14:47:43 localhost-live kwin_wayland[2113]: kwin_core: Failed to open drm node: ""
Sep 17 14:47:43 localhost-live kwin_wayland[2113]: kwin_scene_opengl: couldn't find dev node for drm device
Sep 17 14:47:45 localhost-live ksplashqml[2209]: libEGL warning: egl: failed to create dri2 screen
Sep 17 14:47:46 localhost-live kwin_wayland_wrapper[2243]: Refusing to try glamor on llvmpipe
Sep 17 14:47:46 localhost-live kwin_wayland_wrapper[2243]: EGL setup failed, disabling glamor
Sep 17 14:47:46 localhost-live kwin_wayland_wrapper[2243]: Failed to initialize glamor, falling back to sw
Comment 4 Adam Williamson 2024-09-17 19:20:13 UTC 
I tested with a few different virtual graphics adapter configs, results:

virtio (no 3d passthrough): bad
virtio (w/ 3d passthrough): OK
qxl: OK
vga: bad
Comment 5 Adam Williamson 2024-09-17 20:06:15 UTC 
OK, with a bit more testing this seems to affect all software rendering configs, including qxl. Sometimes the CPU spike isn't there when the system is sat entirely idle, but it always happens on launching firefox, and that always happens much slower on all software rendering configs than it does with the same config on 20240914.n.0. The slowness is also very apparent just in all interactions with the desktop - opening the kicker menu, launching a console, stuff like that. There's clearly *something* worse about the software rendering pipeline in 6.2.
Comment 6 Adam Williamson 2024-09-17 21:14:59 UTC 
Can also reproduce this on a bare metal system, booting with nomodeset to force use of software rendering. I also came up with a simpler test: open a konsole, run 'top' in it, and drag it around in circles for a bit. On my test system, with KDE 6.2 (20240917.n.0), this spikes the CPU usage to 750-800%, and the window moves jerkily. On KDE 6.1 (20240914.n.0), CPU usages hits about 300-350%, and the window moves smoothly.
Comment 7 Adam Williamson 2024-09-17 21:22:00 UTC 
Doing the same thing with hardware rendering on my test system, kwin_wayland spikes to about 35% CPU usage on both images, i.e. there's no difference. The difference is for software rendering only.
Comment 8 Fedora Update System 2024-09-18 20:12:41 UTC 
FEDORA-2024-ab8b79504b (kwin-6.1.90-3.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-ab8b79504b
Comment 9 Fedora Update System 2024-09-18 21:41:23 UTC 
FEDORA-2024-ab8b79504b (kwin-6.1.90-3.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.
Comment 10 Adam Williamson 2024-10-16 16:19:29 UTC 
This actually came back because the patch backport was dropped with the 6.2.0 build, but this fix was not included in 6.2.0 or 6.2.1 upstream :( Re-opening and proposing as an F41 Final FE, because this plays havoc with openQA (and is a bad experience for humans trying to use KDE in a VM or other unaccelerated scenario too).
Comment 11 Fedora Update System 2024-10-16 17:13:03 UTC 
FEDORA-2024-8ef1271562 (kwin-6.2.0-3.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-8ef1271562
Comment 12 Adam Williamson 2024-10-16 17:15:55 UTC 
*** Bug 2319081 has been marked as a duplicate of this bug. ***
Comment 13 Fedora Update System 2024-10-16 17:55:34 UTC 
FEDORA-2024-d7dc366b88 (kwin-6.2.0-3.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-d7dc366b88
Comment 14 Fedora Update System 2024-10-17 02:18:01 UTC 
FEDORA-2024-d7dc366b88 has been pushed to the Fedora 41 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-d7dc366b88`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d7dc366b88

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 15 Fedora Update System 2024-10-17 02:40:16 UTC 
FEDORA-2024-8ef1271562 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-8ef1271562`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-8ef1271562

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 16 Fedora Update System 2024-10-18 01:47:02 UTC 
FEDORA-2024-3d6fe93ff4 has been pushed to the Fedora 41 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-3d6fe93ff4`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-3d6fe93ff4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 17 Fedora Update System 2024-10-18 02:41:14 UTC 
FEDORA-2024-8ef1271562 (kwin-6.2.0-3.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.
Comment 18 Adam Williamson 2024-10-18 17:38:16 UTC 
+4 FE in https://pagure.io/fedora-qa/blocker-review/issue/1714 , marking accepted.
Comment 19 Fedora Update System 2024-10-18 21:19:54 UTC 
FEDORA-2024-3d6fe93ff4 (bluedevil-6.2.1-1.fc41, breeze-gtk-6.2.1-1.fc41, and 66 more) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.