On 21/10/2016 15:27, Chris Wilson wrote:
On Fri, Oct 21, 2016 at 03:11:22PM +0100, Tvrtko Ursulin wrote:
@@ -2236,18 +2233,16 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj)
BUG_ON(obj->base.read_domains & I915_GEM_GPU_DOMAINS);
BUG_ON(obj->base.write_domain & I915_GEM_GPU_DOMAINS);
- max_segment = swiotlb_max_size();
- if (!max_segment)
- max_segment = rounddown(UINT_MAX, PAGE_SIZE);
-
- st = kmalloc(sizeof(*st), GFP_KERNEL);
- if (st == NULL)
- return -ENOMEM;
-
page_count = obj->base.size / PAGE_SIZE;
- if (sg_alloc_table(st, page_count, GFP_KERNEL)) {
- kfree(st);
+ pages = drm_malloc_gfp(page_count, sizeof(struct page *),
+ GFP_TEMPORARY | __GFP_ZERO);
+ if (!pages)
return -ENOMEM;
Full circle! The whole reason this exists was to avoid that vmalloc. I
don't really want it back...
Yes, it is not ideal.
However all objects under 4 MiB should fall under the kmalloc fast path
(8 KiB of struct page pointers, which should always be available), and
possibly bigger ones as well if there is room.
It only fallbacks to vmalloc for objects larger than 4 MiB, when it also
fails to get the page pointer array from the SLAB (GFP_TEMPORARY).
So perhaps SLAB would most of the time have some nice chunks for us to
pretty much limit vmalloc apart for the huge objects? And then, is
creation time for those so performance critical?
I came up with this because I started to dislike my previous
sg_trim_table approach as too ugly. It had an advantage of simplicity
after fixing the theoretical chunk overflow in sg_alloc_table_from_pages.
If we choose none of the two, only third option I can think of is to
allocate the sg table as we add entries to it. I don't think it would be
hard to do that.
Regards,
Tvrtko
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
