[Intel-gfx] GEM memory horror is back :/

[Chris Wilson]

On Sat, 10 Apr 2010 18:18:25 +0200, Clemens Eisserer <linuxhippy at gmail.com> wrote:
> Hi,
> 
> I am not exactly sure what caused it, but today my system did not
> hibernate because too little swap-space.
> /proc/dri/0/gem_objects told me there were over 1Gb of GEM objects
> arround, and I have only 1,5GB swap (which is usually more than enough
> for my type of workload).
> 
> I remember this problem was solved with 2.6.32.2+2.9.1, currently I am
> running 2.6.32.11 + 2.11.

Well the cache pruning both in userspace and with the kernel shrinker both
still exist and have not been modified. So it is unlikely to be a repeat
of those earlier horrors. Instead, we have the spectre of now using tiling
by default in X and thus allocating fenceable buffers for the common case.
The fence requirements impose that bo sizes start from around 1MiB and
grow in powers of two, and this might account for the massive increase in
bo allocation.

The test is quite simple. For your given workload are the number of bo in
existence between 2.10 and 2.11 approximately the same? And yet 2.11 uses
much more memory? If so, for the reason above, the change to use tiling is
the cause.

So we can either back off using tiling for default, in which case we get
yelled at for poor performance again. Or we can switch to allocating
fenceable buffers only at the point of fencing, incurring a performance
hit in those (hopefully) rare cases where either we use the 2D blitter on
pre-i965 or we need to map the buffer back through the GTT (fallbacks, or
perhaps even more frequently, texture uploads (but the 2.11 changes should
have affected mesa so dramatically)).
-ickle

-- 
Chris Wilson, Intel Open Source Technology Centre