https://bugs.kde.org/show_bug.cgi?id=524046
Bug ID: 524046
Summary: kwin_wayland main thread stuck at ~90% CPU
re-importing dma-bufs every frame
(EglDisplay::importDmaBufAsImage →
amdgpu_va_range_alloc2), causing severe input lag
after ~17h session uptime
Classification: Plasma
Product: kwin
Version First 6.7.4
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: performance
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
SUMMARY
After roughly 17 hours of session uptime, kwin_wayland's main thread
spontaneously
ramped up to a sustained 85–97% of one CPU core and stayed there. Keyboard and
mouse
input became visibly laggy across the whole desktop, and the journal filled
with:
kwin_wayland_wrapper: Key repeat discarded, Wayland compositor doesn't seem
to be processing events fast enough!
(339 occurrences in one boot). Overall system load was low — only kwin's main
thread was busy, and GPU utilization (amdgpu gpu_busy_percent) stayed at ~4%,
so the time was spent on the CPU side of the render path, not in actual GPU
work.
A stack sample of the busy main thread (eu-stack, taken repeatedly with the
thread
at ~93% CPU) consistently landed in the dma-buf import path, called from
SurfaceItem::preprocess during compositing — i.e. the import was happening on
(seemingly) every frame instead of once per buffer:
#0 0x00007f8bc1ec15f9
#1 amdgpu_va_range_alloc2 (libdrm_amdgpu)
#2 0x00007f8bb03f635a
#3 0x00007f8bb0359344
#4 dri2_from_dma_bufs (Mesa)
#5 0x00007f8bc20f4ff6
#6 0x00007f8bc20f13f4
#7 0x00007f8bc20e25fd
#8 KWin::EglDisplay::importDmaBufAsImage(KWin::DmaBufAttributes const&)
const
#9 KWin::EglDisplay::importBufferAsImage(KWin::GraphicsBuffer*)
#10 0x00007f8bcd9a39b6
#11 KWin::SurfaceItem::preprocess()
#12 KWin::ItemRendererOpenGL::createRenderNode(...)
#13 KWin::ItemRendererOpenGL::createRenderNode(...)
#14 KWin::ItemRendererOpenGL::createRenderNode(...)
#15 KWin::ItemRendererOpenGL::createRenderNode(...)
#16 KWin::ItemRendererOpenGL::renderItem(...)
#17 KWin::WorkspaceScene::finalDrawWindow(...)
#18 KWin::EffectsHandler::drawWindow(...)
#19 KWin::EffectsHandler::paintWindow(...)
#20 KWin::WorkspaceScene::paintWindow(...)
#21 KWin::WorkspaceScene::paintSimpleScreen(...)
#22 KWin::EffectsHandler::paintScreen(...)
#23 KWin::WorkspaceScene::paint(...)
#24 0x00007f8bcd7a4fc2
#25 KWin::Compositor::composite(KWin::RenderLoop*)
#26 0x00007f8bcabf081b
#27 KWin::RenderLoop::frameRequested(KWin::RenderLoop*)
#28 QObject::event(QEvent*)
... (Qt event loop / QCoreApplication::exec)
All other kwin threads were idle (pthread_cond_wait / ppoll).
Since importBufferAsImage hitting amdgpu_va_range_alloc2 every frame suggests
the
per-buffer EGLImage cache was not being hit (or GPU VA space had become heavily
fragmented / leaked so each allocation became expensive), and the problem
appeared
only after ~17h of uptime and then persisted, this looks like a slow resource
leak or cache-invalidation bug rather than a client misbehaving in the moment.
Things I ruled out before taking the stack trace:
- Not client-driven: I SIGSTOPped every plausible client one at a time and then
in bulk (all 44 Chromium processes at once, Opera, plasmashell, a Wine app,
wezterm, fcitx5, kded6, krunner, kaccess, and Xwayland itself). kwin stayed
at
85–97% in every case.
- Not effects: unloading all effects at runtime (activeEffects empty, blur
unloaded) made no difference.
- Not input events: /proc/interrupts deltas for i8042/xhci/touchpad were zero
over a 3s window while kwin was still at ~90%.
- Not screencasting: no PipeWire screencast streams existed.
- kwin reconfigure and a DPMS off/on cycle did not clear it.
- Voluntary context switches were ~130/s, i.e. kwin was doing ~7–14ms of CPU
work per wakeup at roughly frame-rate cadence — not a tight spin loop.
Restarting the session (new kwin_wayland process) immediately returned kwin to
~5% CPU under the identical workload, which supports state accumulated inside
the kwin process (EGLImage / GPU VA bookkeeping) being the problem.
STEPS TO REPRODUCE
1. Long-running Plasma Wayland session (~17h in my case) on AMD iGPU with an
external HDMI monitor as the only enabled output, typical desktop workload
(Chromium with many windows, terminals, a Wine app).
2. Wait. The issue starts spontaneously; journal shows "Key repeat discarded"
bursts from the onset, becoming continuous within ~10 minutes.
OBSERVED RESULT
kwin_wayland main thread at 85–97% of one core indefinitely; system-wide
keyboard/mouse lag; dma-buf import path hot on every frame per stack samples.
EXPECTED RESULT
Client dma-bufs are imported once per buffer and cached; kwin main-thread CPU
stays in the single digits; no input lag.
SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 6.7.4
KDE Frameworks Version: 6.28.0
Qt Version: 6.11.1
Graphics Platform: Wayland
Kernel: 7.1.6-arch1-1
ADDITIONAL INFORMATION
- Hybrid-GPU laptop (Lenovo 82L5): AMD Cezanne/Renoir iGPU (renders the
session)
+ NVIDIA GA107M (RTX 3050 Mobile, idle). OpenGL renderer: AMD Radeon Graphics
(radeonsi, renoir, ACO), Mesa 26.1.6, libdrm 2.4.134.
- Outputs: internal eDP-1 disabled; single external HDMI-A-1 [email protected],
scale 1, VRR incapable.
- kwin support information from the affected session available on request.
- The affected kwin process had accumulated ~95 min of CPU time over the 17h
session, most of it in the final ~50 minutes.
- Phenomenologically this resembles bug 485425 (effect keeping a stale
reference to a closed window → constant fullscreen repaints for the rest of
the session, fixed in 6.1.3 in the glide effect). Glide is not in use here —
enabled window animations were scale/squash — but the failure mode (repaint
loop surviving every client-side intervention, cleared only by a session
restart) is the same, so this may be a similar stale-reference regression in
a different code path. A Wine/XWayland application (KakaoTalk) was running
in the affected session, as in several reports on that bug.
--
You are receiving this mail because:
You are watching all bug changes.
