[Intel-gfx] Memory leak in drm/i915?

[Jason Detring]

Hello list,

I am seeing a curious memory leak with the Intel X11 driver stack,
specifically the 3D rendering components.

Our application draws a landscape as a series of tiles (i.e. textures
applied to sections of 3D terrain).  This application has other non-3D
modes, and the user is allowed to switch away from and back into the
landscape viewer.  When the user does this the GL contexts are created
and destroyed as needed.

The problem observed is that performing this switch seems to grow system
cache usage by about 1.5 to 2 MB per iteration.  This is unbounded, and
will fill both free memory and swap in the course of a few hours when
running our app in its demonstration cycle.  At this point, the system
becomes unresponsive, eventually dumping the user to a text-mode kernel
panic message.  Killing the app before the hang causes the system cache
and swap to be cleared on an intel-drm-next kernel, but not in the -rc3
kernel (see software stacks later in this message).

At this point we are reasonably sure it isn't in our app.  We have
observed this in both our own app and in a partner's standalone app that
provides an alternate landscape drawing implementation.  These apps work
with no leaks when run atop other desktop and embedded driver stacks.

Our configuration is as follows.
Hardware:  Kontron ETX-PM
- Pentium-M @ 1.6 GHz
- 82855GME graphics controller
- 512 MB memory

Testing software stack:
(I'd like to thank Mr. Vetter for his GTT rewrite work -- it has helped
immensely at making 855-based hardware more stable.  Thank you!)
- Linux 2.6.36-based, on intel-drm-next
27153f72d04bcd83b3a66e219418a21d6269553b
- Mesa 7.8.2
- libdrm 2.4.21
- xf86-video-intel 2.11.0
- xorg-server 1.6.3
- force_s3tc_enable true in /etc/drirc

This problem was originally seen in our current software stack:
- Linux 2.6.36-rc3-based, with the "fix_i8xx_gtt_cache_coherency-9.1"
patch from freedesktop.org bug #27187
- Remainder same as above

This problem was NOT seen on our older stack:
(this stack had other stability issues resolved with the move to a
2.6.36 base)
- Linux 2.6.35.4-based, with the "v9" GTT patch mentioned above
- Remainder same as above

It is probably worth mentioning these upgrade tests had no effect on the
leak.
- Mesa (7.9),
- libdrm (2.4.22, at 362457715faacd3101929e5f0d8ae250d0ad09df),
- xf86-video-intel (2.13.0, at 540c5742186c26c3aeccb7b5d3ff0f374722a20c)


I'm hoping someone sees this, has a "Eureka!" moment, and can inform me
of the exact line to patch.  If not, where do I start?


Thanks,
Jason