Comment # 15
on bug 1204380
from Thomas Zimmermann
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.