drm/i915: allocate large pointer arrays with vmalloc
authorJesse Barnes <jbarnes@virtuousgeek.org>
Fri, 8 May 2009 23:13:25 +0000 (16:13 -0700)
committerEric Anholt <eric@anholt.net>
Tue, 19 May 2009 17:07:14 +0000 (10:07 -0700)
commit8e7d2b2c6ecd3c21a54b877eae3d5be48292e6b5
tree704b3affc3b617be2bcd63ddd9865e9adceeb031
parent1406de8e11eb043681297adf86d6892ff8efc27a
drm/i915: allocate large pointer arrays with vmalloc

For awhile now, many of the GEM code paths have allocated page or
object arrays with the slab allocator.  This is nice and fast, but
won't work well if memory is fragmented, since the slab allocator works
with physically contiguous memory (i.e. order > 2 allocations are
likely to fail fairly early after booting and doing some work).

This patch works around the issue by falling back to vmalloc for
>PAGE_SIZE allocations.  This is ugly, but much less work than chaining
a bunch of pages together by hand (suprisingly there's not a bunch of
generic kernel helpers for this yet afaik).  vmalloc space is somewhat
precious on 32 bit kernels, but our allocations shouldn't be big enough
to cause problems, though they're routinely more than a page.

Note that this patch doesn't address the unchecked
alloc-based-on-ioctl-args in GEM; that needs to be fixed in a separate
patch.

Also, I've deliberately ignored the DRM's "area" junk.  I don't think
anyone actually uses it anymore and I'm hoping it gets ripped out soon.

[Updated: removed size arg to new free function.  We could unify the
free functions as well once the DRM mem tracking is ripped out.]

fd.o bug #20152 (part 1/3)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
drivers/gpu/drm/i915/i915_gem.c
include/drm/drmP.h