| Summary: | 100% cpu usage of kwin_wayland | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Jaime Torres <jtamate> |
| Component: | platform-drm | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | buddha, kde, kde, kt47uo5uvzw, michael.olbrich, msentunali, nate |
| Priority: | NOR | Keywords: | wayland-only |
| Version: | 5.25.4 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/commit/b870ec804b23a727bc926777820107dc5f2567a0 | Version Fixed In: | 5.26 |
| Sentry Crash Report: | |||
| Attachments: | The perf data in txt format | ||
|
Description
Jaime Torres
2022-04-18 09:51:09 UTC
Created attachment 148215 [details]
The perf data in txt format
*** Bug 452657 has been marked as a duplicate of this bug. *** Any ideas? Because I can't work with multi user logged in as the cpu and fan usage is really high then. Another workaround, apart from disabling the cursor animation, seems to be changing the window decorations to plastik. Apparently it is not affected. The maximum peaks I get so far is 20% CPU usage.. (In reply to Jaime Torres from comment #4) > Another workaround, apart from disabling the cursor animation, seems to be > changing the window decorations to plastik. Apparently it is not affected. > The maximum peaks I get so far is 20% CPU usage.. Thanks for some ideas, but nothing helped. What can I do to help finding the bug? I can reproduce a simpler case: run glxgears on a given session switch VT to a terminal kwin_wayland CPU spikes I can reproduce this as well. From what I've seen it happens when kwin is busy with something related to rendering during the VT switch. So any application with continuous frame updates will trigger this. I've attached gdb to see if I can figure out what is going on. It seems kwin is busy looping in the event loop. In QEventDispatcherUNIXPrivate::markPendingSocketNotifiers() pfd.revents is POLLIN for an fd for /dev/dri/card0. I tried to single step through the code to find whatever function should handle this event but I never got anywhere outside the Qt core code. I guess the handler of this event was in some way disabled when switching VTs but the event is still queued. Btw, I'm running 5.25.0 right now but I've seen this with 5.24.5 as well. For me it's the major bug number one. I always have to logout first before I can switch to another user and that's annoying. If I can help with some logging or testing, let me know. I don't know where to begin. Have also tried a clean reinstall. Thanks! *** Bug 456304 has been marked as a duplicate of this bug. *** (In reply to David Edmundson from comment #6) > I can reproduce a simpler case: > > run glxgears on a given session > switch VT to a terminal > > kwin_wayland CPU spikes Can confirm this reproducer works most of the time. A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/3002 Git commit 1d8c9c62cffe74d60636d6840d486a50b7b82003 by Vlad Zahorodnii. Committed on 27/09/2022 at 07:29. Pushed by vladz into branch 'master'. backends/drm: Fix 100% cpu usage after tty switch The drm fd can get stuck in readable state, in which case the QSocketNotifier will fire the activated signal as often as it can leading to high cpu usage. We need to read() the drm fd in order to make the socket notifier stop firing QSocketNotifier::activated. This change removes the m_platform->isActive() check to ensure that drmHandleEvent() gets called, in general, it should be safe as we only notify the outputs about completed pageflips. M +0 -3 src/backends/drm/drm_gpu.cpp https://invent.kde.org/plasma/kwin/commit/1d8c9c62cffe74d60636d6840d486a50b7b82003 Git commit b870ec804b23a727bc926777820107dc5f2567a0 by Vlad Zahorodnii. Committed on 27/09/2022 at 07:48. Pushed by vladz into branch 'Plasma/5.26'. backends/drm: Fix 100% cpu usage after tty switch The drm fd can get stuck in readable state, in which case the QSocketNotifier will fire the activated signal as often as it can leading to high cpu usage. We need to read() the drm fd in order to make the socket notifier stop firing QSocketNotifier::activated. This change removes the m_platform->isActive() check to ensure that drmHandleEvent() gets called, in general, it should be safe as we only notify the outputs about completed pageflips. (cherry picked from commit 1d8c9c62cffe74d60636d6840d486a50b7b82003) M +0 -3 src/backends/drm/drm_gpu.cpp https://invent.kde.org/plasma/kwin/commit/b870ec804b23a727bc926777820107dc5f2567a0 |