https://bugs.kde.org/show_bug.cgi?id=527493
Bug ID: 527493
Summary: KWin main thread stalls up to ~1.4 s under disk load,
scaling with active output count (NVIDIA nvidia-open)
Classification: Plasma
Product: kwin
Version First 6.8.0
Reported In:
Platform: Arch Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: compositing
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
SUMMARY
DISCLOSURE ON AI ASSISTANCE
Full transparency: this investigation was carried out by me working
together with an AI assistant (Hermes Agent, running locally on the
affected machine). The assistant designed and ran the measurement
harness, performed the sampling described below, and drafted this report
under my direction. Every number in this report was produced by commands
executed on my own hardware; nothing here is estimated, extrapolated or
invented. I reviewed the findings and the text, and I can re-run any
measurement or supply raw logs and the harness scripts on request.
I mention this because the report contains an unusual quantity of
quantitative detail, and you should know how it was produced.
On a 3-output NVIDIA Wayland session, KWin's main thread spends a large
fraction of wall-clock time running on-CPU in uninterrupted stretches of
500 ms - 1.45 s while the disk is busy. During those stretches the
compositor does not iterate its event loop, so input events queue up and
the desktop visibly freezes. The effect scales with the number of active
outputs and is essentially absent with a single output.
I am reporting this because I have reproducible numbers rather than a
general "my desktop stutters" complaint, and because the scaling with
output count may narrow down where the cost is coming from.
ENVIRONMENT
OS CachyOS (Arch-based, rolling)
Kernel 6.18.55-2-cachyos-lts (also reproduced on 7.2.11-1-cachyos)
Plasma 6.8.0
KWin 6.8.0-1.1
Qt 6.12.0
Session Plasma Wayland (kwin_wayland, Xwayland enabled)
GPU NVIDIA GeForce RTX 3060 12 GB (GA106, 10de:2504)
Driver nvidia-open 615.78.08 (open kernel modules, GSP 615.78.08)
CPU AMD Ryzen 7 5800X, 32 GB DDR4-3200
Storage btrfs root with compress=zstd:1
Outputs (all [email protected], scale 1):
DP-2 landscape
DP-1 rotated 90 deg (portrait, 1080x1920)
HDMI-A-1 landscape
VRR: all outputs report "incapable". HDR: all outputs "incapable".
SYMPTOM AS A USER
The desktop stutters and briefly freezes when launching applications and
when copying files in Dolphin. With three monitors connected this happens
routinely; with one monitor the desktop is smooth. Nothing in the system
is resource-starved: CPU is 94% idle, 26 GB of 32 GB RAM is available,
and the NVMe benchmarks well above anything the workload needs.
MEASUREMENTS
Method (fully reproducible, no special tools):
Sample /proc/<kwin_pid>/task/<main_tid>/syscall every 4 ms as root.
A sample is classified as "blocking" if the syscall is one of
ppoll/poll/epoll_wait/epoll_pwait/select/futex/nanosleep/accept4/
recvfrom; otherwise the thread is considered to be doing work.
The longest consecutive run of non-blocking samples, times the sample
interval, is the longest continuous main-thread stall.
Load (identical for every run):
Continuous writes of 16 KiB files with os.sync() every 200 files,
for 45-60 s, plus 6 window launches (dolphin/konsole/kcalc) spaced
through the run. Roughly 260,000-310,000 files written per 45 s
(~4,000-7,000 files/s), sustained throughout.
Results, same machine, same driver, same kernel (LTS) unless noted.
Only the number of active outputs varies:
outputs KWin main thread worst single stretches "main thread
busy (% of wall) stall >= 20 ms was hanging"
------------------------------------------------------------------------
1 3.4 % 32 ms 1 0, 0, 0
2 9.8 % 696 ms 8 0, 0
3 19.0 % 1452 ms 13 0, 0, 2
3 19.6 % 944 ms 19 1, 3, 3
Additional runs:
3 outputs, all rotated to landscape 16.6 % 940 ms 12
3 outputs, mainline kernel 7.2.11 25.5 % 1356 ms 18
So worst-case stall goes 32 ms -> 696 ms -> ~1452 ms for 1 -> 2 -> 3
outputs, i.e. roughly +700 ms per additional output. Main-thread busy
time roughly triples from one output to two and doubles again to three.
Main-thread syscall histogram during the 3-output run:
ppoll 73.8 %
running 22.8 % <- state R; the thread is on-CPU, not blocked
ioctl 2.0 %
close 0.5 %
futex 0.0 %
The important part: the stalls are NOT the main thread waiting on the
driver (ioctl is only 2%) and NOT waiting on I/O. The thread is simply
running userspace code for up to a second and a half without returning
to its event loop.
RELEVANT LOGS
At session start with 3 outputs connected (12 lines, all within the same
second), KWin reports output-layer failures that do not appear with one
output (1 line):
kwin_wayland[1104]: Failed to find a working output layer configuration:
EACCESS
kwin_wayland[1104]: Applying output configuration failed: EACCESS
kwin_wayland[1104]: Atomic commit failed: EACCESS
kwin_wayland[1104]: drmModeListLessees() failed: Permission denied
During the stalls:
kwin_wayland[1554]: The main thread was hanging temporarily!
kwin_wayland[1554]: Libinput: event9 - Beken 2.4G Wireless Device:
client bug: event processing lagging behind by 53ms,
your system is too slow
(The second message is the user-visible consequence: input events queued
for 53 ms while the main thread was busy. Note that KWin only logs
"main thread was hanging" for the worst stalls - the 2-output run had a
696 ms stall and logged zero such events, so that log line is not a
reliable indicator of this problem.)
STEPS TO REPRODUCE
1. Connect three displays (here: 2 x DisplayPort + 1 x HDMI, all
1920x1080@60).
2. Start a sustained small-file copy, e.g.
mkdir -p /tmp/ld && cd /tmp/ld
python3 -c "
import os
blk = os.urandom(16*1024)
for i in range(400000):
open(f'f{i}.dat','wb').write(blk)
if i % 200 == 0: os.sync()
"
(Dolphin copying a large source tree from a USB stick reproduced it
in normal use as well.)
3. While that runs, open/close applications and move windows.
4. Observe multi-hundred-millisecond to >1 s freezes of the whole
desktop, and input events arriving late in bursts.
Repeat with a single monitor connected - the freezes essentially
disappear (32 ms worst case).
EXPECTED
Desktop remains responsive while the disk is busy; compositing work per
frame should not scale badly with output count for three 1080p60 outputs,
which is a very light load for this GPU.
ACTUAL
KWin's main thread runs uninterrupted userspace code for 0.5-1.45 s at a
time under this load, blocking input processing and freezing the desktop.
WHAT I HAVE ALREADY RULED OUT (measured, not assumed)
- Storage. 1500 small files copied in 120 ms. 4 KiB random reads under a
concurrent write+fsync stream: p99.9 effectively 0 ms, worst case
1.45 ms. The disk is not the bottleneck.
- CPU scheduling. 1 ms-sleep wake-latency probe while writing 51,893
files: p50 0.06 ms, p99.9 0.15 ms, max 0.55 ms. The kernel scheduler
is not delaying the compositor.
- Memory. 26 GB of 32 GB available, 1.8 MB in swap, no reclaim pressure.
- I/O pressure. /proc/pressure/io "full avg10" was 0.00 across a
15-minute log that captured several KWin hang events.
- Kernel version. Identical behaviour on 6.18.55 LTS and 7.2.11
mainline, so this is not a kernel regression.
- I/O scheduler. bfq vs none on the NVMe: no measurable difference.
- Output rotation. Rotating the portrait output to landscape changed
19.0 % -> 16.6 % and 1452 ms -> 940 ms. Marginal, so rotation is a
minor contributor, not the trigger.
- Output configuration file corruption. kwinoutputconfig.json parses
cleanly: 4 outputs (3 connected + 1 disconnected) and 4 saved setups.
- KWin scripts. Only one non-stock script is installed and it registers
shortcuts at load time only; it has no window or output signal
handlers, so it cannot block window creation.
WHAT I DO NOT KNOW
Whether the per-output cost is in KWin's output-layer/compositing code or
in the NVIDIA DRM path underneath. The EACCES errors at session start and
the clean scaling with output count both point at the output-layer
configuration/commit path, but I have no profile inside KWin itself.
RELATED REPORTS
- NVIDIA/open-gpu-kernel-modules#777 "Stutter in KDE Plasma Desktop when
using GSP firmware" - same class of symptom (opening apps, resizing,
maximizing Dolphin windows) on a 3-output setup. Closed as fixed in
570.124.04, with low-power-state vblank delay left open as #650.
- bugs.kde.org #519461 - consistent freeze/stutter every ~8.5 s on
Plasma/NVIDIA/Wayland.
- bugs.kde.org #521108 - screen freezes for a couple of seconds, same
"kwin_wayland: The main thread was hanging" message. Still UNCONFIRMED.
- bugs.kde.org #511153 - "Failed to find a working output layer
configuration" (resolved for the virtual-output case; this report is
the real-output/EACCES case).
CAVEAT
I could not test Plasma 6.7 for comparison: downgrading kwin 6.7.5 against
kscreenlocker 6.8 fails with
kwin_wayland: symbol lookup error: /usr/lib/libkwin.so.6:
undefined symbol: _ZN12ScreenLocker7KSldApp4lockENS_13EstablishLockEi
so a Plasma 6.7 comparison needs a full environment (live image) rather
than a package downgrade. I have not done that yet, so I cannot say
whether 6.8 introduced this or merely made it worse.
I am happy to run further instrumentation (e.g. a build with profiling or
a bpftrace script) if that would help localise the cost.
--
You are receiving this mail because:
You are watching all bug changes.
