** Description changed: [ Impact ] The gnome-shell process leaks shared memory from software-rendered elements (like GTK3 windows) if they continue to redraw in the background while not being displayed on screen, such as during the lock screen. This primarily affects Intel GPUs due to a Mesa bug, but could affect other drivers too. + In the most extreme case, a window updating faster than the refresh rate + of the monitor will cause the compositor to use hundreds of megabytes + shared memory more than it should, even while the desktop is visible. + [ Test Plan ] 0. Find a machine with Intel graphics. 1. Install gnome-terminal (not ptyxis or any other terminal): - sudo apt install gnome-terminal + sudo apt install gnome-terminal 2. Log in via ssh to monitor resource usage: - while sleep 5; do grep Shm /proc/meminfo; done + while sleep 5; do grep Shm /proc/meminfo; done 3. Log in to the GNOME desktop and start a gnome-terminal window animating: - while sleep 1; do date; done + while sleep 1; do date; done 4. Lock the screen. - 5. Observe the shared memory stats via your ssh login. Verify that the Shmem and - ShmemHugePages values do not increase by more than 100MB even after 15 - minutes. + 5. Observe the shared memory stats via your ssh login. Verify that the Shmem and + ShmemHugePages values do not increase by more than 100MB even after 15 + minutes. [ Where problems could occur ] The Mesa fix affects all Gallium drivers that don't already set a memory budget themselves. So it affects Intel graphics, but not (any/all?) Radeon systems. If a code path existed that was relying on the previous behaviour of never throttling uploads (and thus their OpenGL calls never blocking) then new compositor bugs could arise in theory. The Mutter workaround (if applied) flushes OpenGL work to the GPU early so can affect desktop performance in extreme cases with hundreds of windows. Although it actually improves performance before that threshold. The Mutter workaround could also interfere with the manual command journalling that Cogl does internally for Mutter, resulting in unpredictable graphics behaviour in the worst case. [ Original description ] ShmemHugePages grows continuously while the screen is locked, consuming all 64GB RAM + 8GB swap, triggering the OOM killer. No single process accounts for the shmem — pages are orphaned in pagecache. Hardware — Lenovo ThinkPad 21QDCTO1WW, intel 225H CPU, with ARC 130T GPU. Software — Ubuntu version, kernel 6.17.0-1012-oem, GNOME on Wayland, GPU driver version: Kernel driver in use: i915 Kernel modules: i915, xe Steps to reproduce — Log in to GNOME Wayland session, lock the screen, leave idle for 3-7 hours, observe ShmemHugePages in /proc/meminfo growing continuously Evidence — Attach shmem_track.txt The issue started post update to the 6.17.0-1012-oem. This has repeated multiple times over the last 3 days. The entire gnome session and, in some cases, even the psmouse driver got killed when I left the laptop untouched for hours. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-oem-6.17-headers-6.17.0-1012 6.17.0-1012.12 ProcVersionSignature: Ubuntu 6.17.0-1012.12-oem 6.17.9 Uname: Linux 6.17.0-1012-oem x86_64 ApportVersion: 2.28.1-0ubuntu3.8 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Mar 2 23:49:53 2026 InstallationDate: Installed on 2026-02-12 (18 days ago) InstallationMedia: Ubuntu 24.04.3 LTS "Noble Numbat" - Release amd64 (20250805.1) PackageArchitecture: all ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> SourcePackage: linux-oem-6.17 UpgradeStatus: No upgrade log present (probably fresh install)
** Description changed: [ Impact ] The gnome-shell process leaks shared memory from software-rendered elements (like GTK3 windows) if they continue to redraw in the background while not being displayed on screen, such as during the lock screen. This primarily affects Intel GPUs due to a Mesa bug, but could affect other drivers too. In the most extreme case, a window updating faster than the refresh rate of the monitor will cause the compositor to use hundreds of megabytes - shared memory more than it should, even while the desktop is visible. + more shared memory than it should, even while the desktop is unlocked + and visible. [ Test Plan ] 0. Find a machine with Intel graphics. 1. Install gnome-terminal (not ptyxis or any other terminal): sudo apt install gnome-terminal 2. Log in via ssh to monitor resource usage: while sleep 5; do grep Shm /proc/meminfo; done 3. Log in to the GNOME desktop and start a gnome-terminal window animating: while sleep 1; do date; done 4. Lock the screen. 5. Observe the shared memory stats via your ssh login. Verify that the Shmem and ShmemHugePages values do not increase by more than 100MB even after 15 minutes. [ Where problems could occur ] The Mesa fix affects all Gallium drivers that don't already set a memory budget themselves. So it affects Intel graphics, but not (any/all?) Radeon systems. If a code path existed that was relying on the previous behaviour of never throttling uploads (and thus their OpenGL calls never blocking) then new compositor bugs could arise in theory. The Mutter workaround (if applied) flushes OpenGL work to the GPU early so can affect desktop performance in extreme cases with hundreds of windows. Although it actually improves performance before that threshold. The Mutter workaround could also interfere with the manual command journalling that Cogl does internally for Mutter, resulting in unpredictable graphics behaviour in the worst case. [ Original description ] ShmemHugePages grows continuously while the screen is locked, consuming all 64GB RAM + 8GB swap, triggering the OOM killer. No single process accounts for the shmem — pages are orphaned in pagecache. Hardware — Lenovo ThinkPad 21QDCTO1WW, intel 225H CPU, with ARC 130T GPU. Software — Ubuntu version, kernel 6.17.0-1012-oem, GNOME on Wayland, GPU driver version: Kernel driver in use: i915 Kernel modules: i915, xe Steps to reproduce — Log in to GNOME Wayland session, lock the screen, leave idle for 3-7 hours, observe ShmemHugePages in /proc/meminfo growing continuously Evidence — Attach shmem_track.txt The issue started post update to the 6.17.0-1012-oem. This has repeated multiple times over the last 3 days. The entire gnome session and, in some cases, even the psmouse driver got killed when I left the laptop untouched for hours. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-oem-6.17-headers-6.17.0-1012 6.17.0-1012.12 ProcVersionSignature: Ubuntu 6.17.0-1012.12-oem 6.17.9 Uname: Linux 6.17.0-1012-oem x86_64 ApportVersion: 2.28.1-0ubuntu3.8 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Mar 2 23:49:53 2026 InstallationDate: Installed on 2026-02-12 (18 days ago) InstallationMedia: Ubuntu 24.04.3 LTS "Noble Numbat" - Release amd64 (20250805.1) PackageArchitecture: all ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> SourcePackage: linux-oem-6.17 UpgradeStatus: No upgrade log present (probably fresh install) ** Tags added: performance -- 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: [i915] ShmemHugePages leak during GNOME lock screen To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell/+bug/2143073/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
