[kwin] [Bug 523812] kwin_wayland leaks screen-sized DRM buffers during rendering: ~1.4 GB/hour of active use, zero when idle

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.