[kwin] [Bug 524046] New: kwin_wayland m ain thread stuck at ~90% CPU re-importing dma -bufs every frame (EglDisplay::importDmaBufAs Image → amdgpu_va_range_alloc2), causing se vere input lag after ~17h session uptime

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.