https://bugs.kde.org/show_bug.cgi?id=524046
Christian Galo <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |feichang.catering590@passma | |il.net --- Comment #1 from Christian Galo <[email protected]> --- Confirming this on different hardware, with a quantified degradation curve. Same stack, same symptom, but the onset here is roughly 5x faster than the 17h in the original report: this machine crosses 25% of a core within ~60 minutes of session start and is still climbing at the 2h mark. ENVIRONMENT Plasma / KWin 6.7.4 (Wayland) KF6 6.29.0 Qt 6.11.2 Mesa 26.1.8 (radeonsi) libdrm 2.4.134 Kernel 7.1.13 (Fedora 44) GPU AMD Phoenix1 [1002:15bf], Radeon 760M, DCN 3.1 (integrated, single GPU, no hybrid/discrete secondary) Outputs eDP-1 2256x1504@60, fractional scale 1.50 DP-3 3840x2160@60, fractional scale 1.45 Note one non-default kernel arg: amdgpu.dcdebugmask=0x10 (PSR disabled). It was added for an unrelated panel issue and is present both before and after; it does not affect this behaviour. Differences from the original report worth noting: that reporter was on a single 1920x1080@60 external at scale 1, on Cezanne/Renoir. This is a newer APU generation driving two outputs, one of them 4K, both at fractional scale. If the rate of growth tracks the number of dma-buf imports per second, that difference is a plausible explanation for the much faster onset -- and would be a useful lever for anyone trying to reproduce this quickly. STACK SAMPLING Sampled the main thread with `eu-stack -p $(pgrep -x kwin_wayland)` at ~0.3s intervals, two separate runs of 12 samples each, taken while the process sat at ~60% of a core. Run 1: 4/12 samples with amdgpu_vamgr_find_va as the leaf frame Run 2: 6/12 samples with amdgpu_vamgr_find_va as the leaf frame (remainder were ppoll in the event loop, plus one Region::subtractBands and one WorkspaceScene::frame) Representative stack, innermost first: #0 amdgpu_vamgr_find_va #1 amdgpu_va_range_alloc2 #2 amdgpu_bo_from_handle #3 si_texture_from_handle #4 dri2_from_dma_bufs #5 dri2_create_image_dma_buf #6 dri2_create_image #7 _eglCreateImageCommon #8 KWin::EglDisplay::importDmaBufAsImage(KWin::DmaBufAttributes const&) const #9 KWin::EglDisplay::importBufferAsImage(KWin::GraphicsBuffer*) #10 KWin::BufferTextureOpenGL::attach(KWin::GraphicsBuffer*, KWin::Region const&, std::shared_ptr<KWin::SyncReleasePoint> const&) #11 KWin::SurfaceItem::preprocess() #12 KWin::ItemRendererOpenGL::createRenderNode(...) #15 KWin::ItemRendererOpenGL::renderItem(...) So: the import is happening inside per-frame rendering rather than once per buffer, and the cost is inside libdrm's VA range allocator rather than in the import itself. DEGRADATION CURVE Sampled kwin_wayland's utime+stime from /proc every 30s across a whole session (226 samples, minutes 4 through 117 of session uptime), bucketed by session age: session age kwin CPU (% of one core) 0-15 min 9.2 avg (min 8, max 12) 15-30 min 12.0 avg (min 9, max 17) 30-45 min 16.5 avg (min 14, max 19) 45-60 min 18.0 avg (min 15, max 25) 60-75 min 24.5 avg (min 20, max 27) 75-90 min 23.4 avg (min 15, max 28) 90-120 min 26.1 avg (min 24, max 29) Linear fit over the first 80 minutes: +0.249 percentage points of one core per minute (~15 points/hour), intercept 6.7%. Extrapolating that slope: 40% at ~2.2h, 60% at ~3.6h, 90% at ~5.6h of session uptime -- which matches what this machine actually does; by the end of a working day kwin_wayland sits at 55-65% and the desktop judders continuously. A fresh session starts at ~5% of a core. WHAT CORRELATES AND WHAT DOESN'T - The climb is NOT proportional to client activity. Across a 90-minute window with an essentially fixed set of clients, kwin CPU roughly tripled while the clients' own CPU was flat. Sampling kwin against the busiest clients at 1s resolution shows kwin holding a steady floor while client CPU swings widely around it. - Closing a heavy client (Firefox) dropped kwin from ~28% to ~16% and its RSS from 347MB to 265MB, but did NOT return it to the ~5% baseline of a fresh session. So client surfaces add to the per-frame cost, but the accumulated component stays behind when they leave. - kwin RSS grows only modestly over the session (250MB -> ~350MB with clients), so this does not look like a straightforward buffer leak in kwin itself. RULED OUT ON THIS MACHINE Disk I/O none (device idle; the high PSI io / iowait figures on this box are a phantom-iowait artifact -- procs_blocked pinned at 4 with zero tasks actually in D state) CPU throttling governor and EPP both performance, 4.69GHz sustained, 56-60 C Memory pressure PSI memory 0.00, no direct reclaim or compaction in steady state GPU saturation gpu_busy_percent ~16, VRAM 1.7GB of 4GB Input devices no USB interrupt storm; touchpad judders identically to external mouse Screencast no active PipeWire video streams Effects blur disabled made it slightly worse (68% vs 60%); tearing disabled, no change Display config unplugging the external output did not clear it Happy to test patches, run instrumented builds, or collect anything else useful -- this reproduces here every single session, within an hour, so turnaround is quick. -- You are receiving this mail because: You are watching all bug changes.
