https://bugs.kde.org/show_bug.cgi?id=527493
--- Comment #1 from [email protected] --- Follow-up: I profiled the stall with perf, and the open question from the original report (KWin's output-layer code vs the NVIDIA DRM path underneath) is now answered. METHOD perf record -F 999 -t <kwin_wayland main tid> under the same sustained small-file write load, 2 outputs connected. kernel.kptr_restrict had to be temporarily lifted from 2 to 0 to resolve kernel/module symbols; it was restored immediately afterwards. TIME BY MODULE, ON KWIN'S MAIN THREAD [nvidia] (kernel module) 48.7 % [kernel.kallsyms] 39.1 % libkwin.so.6.8.0 3.6 % libnvidia-eglcore.so 2.6 % libc.so.6 1.6 % Top kernel symbols: 18.9 % _raw_spin_lock_irqsave 5.3 % rwsem_spin_on_owner 1.3 % memset So roughly 88 % of the main thread's time is kernel-side and roughly 49 % is inside the NVIDIA module. KWin's own userspace code is under 4 %. The thread is not computing - it is contending on kernel locks. THE CALL PATH kwin_wayland -> ioctl -> entry_SYSCALL_64_after_hwframe -> do_syscall_64 -> __x64_sys_ioctl -> drm_ioctl -> drm_ioctl_kernel -> drm_mode_getconnector -> drm_helper_probe_single_connector_modes -> [nvidia module, unexported frames] -> _raw_spin_lock_irqsave 18.8 % Almost the entire 18.8 % is spinlock/rwsem contention reached through the driver's get_modes path, invoked from DRM_IOCTL_MODE_GETCONNECTOR. CONSISTENT WITH THE ORIGINAL REPORT - stack samples previously caught the main thread in KWin::DrmBackend::updateOutputs() -> KWin::DrmGpu::updateOutputs() -> KWin::DrmConnector::updateProperties() -> drmIoctl, in 14 of 60 samples. - a DRM ioctl trace showed 56 DRM_IOCTL_MODE_GETPROPERTY and 40 DRM_IOCTL_MODE_ATOMIC inside a single second. Taken together: the compositor appears to re-probe connector modes repeatedly rather than once per hotplug, and each probe is expensive inside the NVIDIA driver. TWO QUESTIONS I CANNOT ANSWER FROM THE REPORTER SIDE 1. Is KWin expected to call drm_mode_getconnector / probe connector modes repeatedly during steady-state operation, or only on hotplug and configuration change? If the latter, something is generating repeated output-change events. I measured DRM "change" uevents on card1 at up to ~18 within 25 s in one window (and zero in others), so a re-probe trigger is plausible. 2. Whether that much spinlock contention inside nvidia_get_modes is expected - NVIDIA would know better than I would. Happy to add more instrumentation (bpftrace call counts for drm_mode_getconnector per second, or the same profile per output count) if useful. -- You are receiving this mail because: You are watching all bug changes.
