https://bugzilla.suse.com/show_bug.cgi?id=1204380 https://bugzilla.suse.com/show_bug.cgi?id=1204380#c15 Thomas Zimmermann <tzimmermann@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(jgross@suse.com) --- Comment #15 from Thomas Zimmermann <tzimmermann@suse.com> --- Hi (In reply to J�rgen Gro� from comment #14)
(In reply to Thomas Zimmermann from comment #13)
Hi,
there are plenty of internal information at /sys/kernel/debug/dri/0/. After running the leaky code for a while, can you please retrieve the following files:
sudo cat /sys/kernel/debug/dri/0/clients sudo cat /sys/kernel/debug/dri/0/framebuffer sudo cat /sys/kernel/debug/dri/0/i915_gem_objects
Please also see if their content changes over time. The last file has information about memory allocation that might be helpful. Does it go up?
# cat /sys/kernel/debug/dri/0/clients command pid dev master a uid magic X 2321 0 y y 0 0 X 2321 0 n y 0 2 X 2321 0 n y 0 3 X 2321 0 n y 0 4 X 2321 0 n y 0 5 X 2321 0 n y 0 6 X 2321 0 n y 0 7 X 2321 0 n y 0 1 firefox 23630 128 n n 1000 0 X 2321 0 n y 0 8 X 2321 0 n y 0 9 X 2321 0 n y 0 10 thunderbird-bin 23974 128 n n 1000 0 X 2321 0 n y 0 11 X 2321 0 n y 0 12 X 2321 0 n y 0 13 X 2321 0 n y 0 14 Keybase 24435 128 n n 1000 0 X 2321 0 n y 0 15 electron 24645 128 n n 1000 0 X 2321 0 n y 0 16 X 2321 0 n y 0 17 electron 24832 128 n n 1000 0 X 2321 0 n y 0 18 X 2321 0 n y 0 19 RDD Process 25416 128 n n 1000 0 X 2321 0 n y 0 20 X 2321 0 n y 0 21 X 2321 0 n y 0 22
Quite a bit of X here, but maybe not a problem.
# cat /sys/kernel/debug/dri/0/framebuffer framebuffer[140]: allocated by = X refcount=7 format=XR24 little-endian (0x34325258) modifier=0x100000000000001 size=5760x1200 layers: size[0]=5760x1200 pitch[0]=23040 offset[0]=0 obj[0]: name=0 refcount=7 start=00000000 size=29360128 imported=no framebuffer[97]: allocated by = [fbcon] refcount=1 format=XR24 little-endian (0x34325258) modifier=0x0 size=1920x1080 layers: size[0]=1920x1080 pitch[0]=7680 offset[0]=0 obj[0]: name=0 refcount=3 start=00000000 size=8294400 imported=no
Looks normal.
# cat /sys/kernel/debug/dri/0/i915_gem_objects 1166 shrinkable [0 free] objects, 1291399168 bytes
That's a lot of objects. I have ~250 to 350 on my system with i915 and Tumbleweed. It goes up and down, but remains within that range.
system: total:0x00000007be357000, available:0x00000007be357000 bytes stolen-system: total:0x0000000004000000, available:0x0000000004000000 bytes
Note that shared memory allocations were up to about 20GB when taking this data, according to the page owner data most of that was allocated by i915.
Some minutes after above snapshot I'm seeing:
# cat /sys/kernel/debug/dri/0/i915_gem_objects 1224 shrinkable [0 free] objects, 716410880 bytes
Number of objects is going up, but the storage memory is going down. Maybe you're leaking object instances (in contrast to full buffers). What's your graphics environment? Can you run with a different desktop/window manager and observe the changes to these files? I'd like to rule out a bug in the userspace code. -- You are receiving this mail because: You are on the CC list for the bug.