Successful Noble backport test: upstream Mutter !5285 fixes locked- session GPU-memory accumulation on AMD
Please consider a mutter SRU/backport to Ubuntu 24.04 (Noble) of: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/5285 https://github.com/GNOME/mutter/commit/af926cffa0702d1fbd0f2b87f9adbfcb8be0e9f6 Michel Dänzer's "renderer/native: Don't keep around detached onscreens in power saving", merged 3 September 2026, closes upstream issues 4101 and 5008. I reproduced locked-session GPU-memory accumulation and verified that backporting this commit stops it on my machine. Environment: - Ubuntu 24.04.4 LTS, GNOME Wayland - Kernel 7.0.0-31-generic - AMD GPU PCI ID 1002:7550, amdgpu, approximately 16 GiB VRAM - gnome-shell 46.0-0ubuntu6~24.04.13 - Original libmutter-14-0 46.2-1ubuntu0.24.04.14 - Mesa 25.2.8-0ubuntu0.24.04.2 Measurement method: approximately 30-second snapshots of /proc/meminfo, AMD mem_info_vram_used/mem_info_gtt_used, session LockedHint, and per- process DRM fdinfo. DRM clients were identified by device/client ID rather than summing duplicate file descriptors. Before patch: - During approximately 52 minutes locked, GNOME Shell's drm-resident-vram rose from 0.47 GiB to 13.70 GiB, with steady-state growth approximately 15.5 GiB/hour. - Chrome and the terminal's graphics allocations stayed essentially flat. - GNOME Shell VRAM dropped to 0.43 GiB on unlock. Unlike some reports above, my accumulated memory was released on unlock without restarting the shell. - System RAM remained stable and swap unused during this short reproduction. An earlier overnight lockup had sustained system-memory exhaustion, but VRAM spillover was not directly recorded in that earlier incident. After patch: - Applied the upstream commit to the exact Ubuntu .14 source; all three hunks applied with zero fuzz (line offsets only). - Built local packages 46.2-1ubuntu0.24.04.14+lockupfix1 and logged out/in to load them. - During 29 minutes 34 seconds of locked samples, GNOME Shell drm-resident-vram stayed exactly 358.0390625 MiB in every sample. Its resident GTT stayed 18.01953125 MiB. - Global VRAM settled around 583 MiB and GTT around 63 MiB; no accumulating trend and no swap use. At the original rate, this interval would have added approximately 7.6 GiB. - This is a successful approximately 30-minute hardware regression test, not yet an overnight endurance test. The upstream explanation matches this growth/release pattern: view rebuilds retain old framebuffers in detached_onscreens, but normal cleanup follows modesets, which do not run during power saving. The fix avoids retaining detached onscreens during power saving and clears existing retained ones on the power-save path. I have not separately traced hotplug events or the list length on this machine. Build/test note: 179 normal-suite passes, 5 expected failures, 1 failure; another 7 passes in the flaky suite. The one failure, /backends/monitor/custom/second-rotated-tiled-config (output count 2 versus expected 1), reproduces at the same assertion with the original official Ubuntu .14 libmutter binary in the same container test environment, so it is not introduced by this backport. Could this report be triaged against mutter and the upstream fix considered for a Noble SRU? The currently published .16 package does not include it. This AMD result may also help establish that the affected path is not specific to Intel or the OEM kernel, although I cannot claim every variant reported here has the same cause. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2143073 Title: ShmemHugePages leak during GNOME lock screen on 6.17.0-1012-oem causes OOM To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2143073/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
