Hi Maaz, Zack,
Yes, it does, and I have to correct my message of 8 August as well.
-- Short answer
With 3D disabled again, kernel 7.1.8, stock mesa 26.1.6-arch3.1. Object
counts from vmwgfx_gem_info, sampled every 15 minutes:
2026-08-15 14:22 - 23:53 idle, 9.5 h 370 -> 370 objects
2026-08-15 23:53 - 16 01:08 in use 370 -> 772 objects
2026-08-16 03:54 - 13:53 idle, 9.8 h 1274 -> 1274 objects
2026-08-16 13:55 - 17:57 working day 1274 -> 2387 objects
Both idle windows are identical in every single sample: 39 and 40
consecutive samples with the same object count and the same pool
figures. Not approximately flat - identical. Nothing accumulates while
the machine sits there, and nothing is handed back either.
I lead with counts rather than volume because of the caveat in my first
mail: the summed object sizes exceed physical RAM, so I do not trust the
totals. For what it is worth, the pools moved 2.16 -> 4.57 GB and 6.73
-> 13.85 GB across those two active windows.
-- This confirms my original report rather than adding to it:
The second window was a browser video call, with no RDP session
involved. In some of my later messages I linked the heavy phases to RDP,
because that was the heaviest thing running here. That was my own
mistake: my first report already said it plainly - "a browser window
with a looping CSS animation makes it measurable within minutes.
Opening and closing 32 windows produced no growth at all, so it is the
continuous rendering that drives it." The idle-versus-active split I
described then is exactly what these four windows show.
-- Correction to my message of 8 August:
I wrote that enabling 3D acceleration made the leak go away. That was
based on two svga sessions of 15.6 and 18.2 hours, and it does not
survive a longer measurement.
The problem was the length of those sessions, not the pools - I did
report both, and mob_ttm was already moving in that table. But at 18.2
hours it stood at 0.555 GB. That same boot ran on for 115.5 hours in
total, and by the end mob_ttm was at 15.15 GB.
For reference, the two pools swap roles with the configuration:
3D off (llvmpipe) system_ttm grows, mob_ttm flat at 0.023 GB
3D on (svga) system_ttm flat, mob_ttm 0.27 -> 15.15 GB
Per boot, both pools added together:
boot hours kernel 3D sys+mob objects
2026-08-02 16:02 7.8 7.1.5 off +1355 MB/h 753 -> 2184
2026-08-03 04:33 34.8 7.1.5 off +1367 MB/h 23 -> 8211
2026-08-04 15:34 33.1 7.1.6 off +989 MB/h 31 -> 5586
2026-08-06 00:56 25.7 7.1.6 off +667 MB/h 49 -> 2680
2026-08-07 02:45 15.6 7.1.6 on +5 MB/h 85 -> 244
2026-08-07 18:32 115.5 7.1.6 on +161 MB/h 1357 -> 9128
2026-08-12 14:20 62.9 7.1.8 on +30 MB/h 1405 -> 4418
2026-08-15 12:03 29.6 7.1.8 off +442 MB/h 30 -> 2236
The 2026-08-07 18:32 row is the one I got wrong. I reported +22 MB/h
for its first 18.2 hours; over the full 115.5 hours it is +161 MB/h.
I drew a conclusion from a session that had not run long enough.
So enabling 3D reduces it substantially - roughly a factor 3 to 30
depending on the session - but it does not remove it. The per-boot
averages also flatten something that is not gradual: long flat
stretches, then a jump inside a single 15-minute sample.
-- The kernel changed twice and I did not mention it:
7.1.5 -> 7.1.6 on 4 August, 7.1.6 -> 7.1.8 on 12 August, each taking
effect at the boot immediately after. Since vmwgfx is a kernel module I
should have said so at the time. Mesa stayed at 3:26.1.6-1 throughout,
so that is not a variable.
I do not think it explains anything - 7.1.8 with 3D off leaks harder
than 7.1.5 did - but it belongs in the data.
-- The patch:
Still built and still verified here:
/usr/lib/libgallium-26.1.6-arch3.1.so vmw_winsys_to_dma_buffer absent
my staging/26.1 build at 2ed36c6 vmw_winsys_to_dma_buffer
present
"Mesa 26.1.6 (git-2ed36c6b5d)"
Arch has not shipped a mesa containing it; 3:26.1.6-1 is still the
current package here, so the fix has not reached this machine through
the distribution.
In the 3D-off configuration llvmpipe is in use and the buffers are dumb
buffers of 1920x1088x4, so I would not expect gallium svga to be
involved at all. If the mechanism Zack described - prime exports with no
deref/destroy ioctl, so gem_close does nothing - also applies on the
dumb-buffer path, that would explain why this configuration keeps
leaking while the mesa-side fix sits in svga.
I can run any of these, whichever is most useful to you. All four are
set up here, so it is a matter of you saying which:
1. the patched build with 3D OFF, in the current configuration. This
is the quickest - the build is in place and it takes a re-login.
I expect it to change nothing, since svga is not loaded here, but
that is worth establishing rather than assuming.
2. the patched build with 3D ON, 48 hours or more, against the
+161 MB/h baseline above. Needs the VM powered down to change the
host setting, so give me a day for it.
3. stock Arch kernel instead of the CachyOS one. Arch currently ships
linux 7.1.8.arch1-3, which is the same version as the CachyOS
7.1.8 I am running, so that isolates the patch set rather than the
version. I offered a vanilla kernel in my first mail and never did
it; it installs alongside the current one, so it is low risk here.
4. any instrumentation you want, on either configuration - extra
debugfs reads, a debug patch, different sampling.
Say which and I will run it.
-- One correction on the plasmashell crash:
In my 8 August mail I said the dmabuf import crash looked like a KDE bug
and that I would report it to them. That was wrong. The message comes
from libgallium, not from any KDE or Qt library, and the faulting thread
is an llvmpipe rasteriser thread. It matches mesa issue #6438, which is
still open. I will add my reproduction there instead.
Regards,
Jellis Onsea
AccessWeb
Op 13-08-2026 om 23:12 schreef Maaz Mombasawala:
That is good to know. Do you still see a memory leak with 3D off?
--
Met vriendelijke groeten,
AccessWeb ICT Solutions
AccessWeb.
ONSEA Jellis
AccessWeb ICT Solutions
Europaplein 29/7
3630 Maasmechelen
Tel BE +32 470 96 43 15 <tel:+32470964315>
Tel NL +31 6 492 757 98 <tel:+31649275798>
E-mail [email protected] <mailto:[email protected]>
Indien u een SLA-contract heeft, gelieve alle communicatie te voeren met
het e-mailadres gekoppeld aan uw SLA. Dit verzekert de correcte en
tijdige opvolging van uw vraag.
