https://bugs.kde.org/show_bug.cgi?id=523812
--- Comment #1 from AccessWebBE <[email protected]> --- Follow-up: the memory is --not-- released when the compositor exits, only on a full reboot. This changes the picture I described in the original report, so I would rather correct it than leave it standing. - What I did: At 34.5 hours of uptime I logged out of the Plasma session and logged back in, without rebooting the machine. `kwin_wayland` was restarted by that (pid 2612 -> 3156650); the machine itself stayed up. I measured immediately before and after. - Measurements ``` before logout after re-login kwin_wayland GEM objects 8139 19 system_ttm usage 49.47 GB 45.80 GB GPUActive (/proc/meminfo) 10.86 GB 11.06 GB MemAvailable 11.06 GB 13.32 GB ``` For comparison, the figures in the original report were taken at 9 hours of uptime: 1846 objects and system_ttm at 12.76 GB. So the accumulation simply continued over the following day. After a real reboot (same session type, same workload profile): ``` GPUActive 0.11 GB RAM in use 4.5 GB of 31 GB ``` - What this suggests: `kwin_wayland` does release its buffers when it exits: its GEM object count drops from 8139 to 19. But the memory does not come back. `system_ttm` falls by only 3.67 GB, and `GPUActive` does not fall at all — it is marginally higher afterwards. The ~2.3 GB gained in `MemAvailable` is very likely just the browsers and editors from the old session being closed, not graphics memory. At the moment of the second measurement, --no DRM client held more than 19 GEM objects in total--, yet TTM still reported roughly 46 GB in use. That makes me doubt my original framing of "a userspace reference leak in the compositor". If it were purely that, exiting the compositor should have returned the memory. It looks more like the pages are not returned by the vmwgfx/TTM layer, or something else is still holding them. I do not know which, and I would rather not guess further. - A caveat about my own numbers: The sum of GEM object sizes I reported originally (and again here: 8139 objects totalling ~46.6 GB) exceeds the physical RAM of this machine (31 GiB). That sum therefore overcounts — presumably shared or multiply-mapped objects are counted more than once. The object -count- is reliable; for volume, `system_ttm` and `MemAvailable` are the figures I would trust. I mention this so the earlier byte totals in this report are read with that in mind. `system_ttm` reporting ~46-49 GB on a 31 GiB machine is itself something I cannot fully explain. My assumption is that TTM accounts pages it has evicted to shmem (which land in zram swap here), while `GPUActive` counts only resident ones. If that assumption is wrong, the volume figures need reinterpreting — the trend and the object counts stand either way. - How to reproduce the measurements: ```sh # object count and per-client totals (root) grep -c bytes /sys/kernel/debug/dri/0/vmwgfx_gem_info awk '/^ *pid/{p=$2" "$4} /bytes/{n[p]++; s[p]+=$2} \ END{for(k in n) printf "%-26s %6d objects %9.1f MB\n", k, n[k], s[k]/1048576}' \ /sys/kernel/debug/dri/0/vmwgfx_gem_info | sort -k3 -rn # pool usage (root) awk '/usage:/{print $2}' /sys/kernel/debug/dri/0/system_ttm # resident graphics memory grep -E 'GPUActive|GPUReclaim' /proc/meminfo ``` Environment is unchanged from the original report, except that the kernel is now 7.1.6 (CachyOS) rather than 7.1.5; the measurements above were taken on 7.1.5. Happy to run anything specific if it would help narrow this down — the machine reproduces it reliably within a working day. Adding two attachments: - Measurements before logging out (34.8 h uptime) - Measurements after logging back in, same uptime, no reboot -- You are receiving this mail because: You are watching all bug changes.
