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

Dave Airlie airlied at gmail.com
Sun Apr 11 09:54:16 CEST 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:
>> 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.

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.

Dave.



More information about the Intel-gfx mailing list