[Intel-gfx] GEM memory horror is back :/
airlied at gmail.com
Sun Apr 11 00:54:16 PDT 2010
On Sun, Apr 11, 2010 at 2:35 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Sat, 10 Apr 2010 18:18:25 +0200, Clemens Eisserer <linuxhippy at gmail.com> wrote:
>> 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 184.108.40.206+2.9.1, currently I am
>> running 220.127.116.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.
I've wondered before, back when I worked on a TTM driver as well, whether
the 1MB needed backing pages allocated to it, or if you just needed a 1MB
space in the GTT.
My memory of how tiling works is vague enough though.
More information about the Intel-gfx