Re: [PATCH 1/2] drm/i915: introduce and use i915_gem_object_map_range()

[Dave Gordon <david.s.gordon@intel.com>]

On 13/04/16 21:14, Chris Wilson wrote:
> On Wed, Apr 13, 2016 at 09:00:53PM +0100, Dave Gordon wrote:
>> From: Alex Dai <yu.dai@intel.com>
>>
>> The recent pin-and-map unification didn't include the command parser's
>> own custom vmapping code, which essentially duplicates the same
>> algorithm but without some of the optimisations.
>
> No. There is no need for extra hacks for the cmdparser when the very
> issue is that it takes a vmap every batch.
> -Chris

Actually, sharing your mapping code will mean that it won't use vmap() 
for "sufficiently small" batches (i.e. one page), it will take the kmap 
path instead. And then for larger batches it will take advantage of the 
stack optimisation instead; only the largest won't benefit from that.

Even without the utility of sharing the code with the command parser, 
I'd still be inclined to refactor the pin-and-map into the function that 
does the mapping, with whatever clever optimisations we can apply, and 
the outer wrapper that manages the pinning and error recovery.

BTW, I expected to find a kvunmap() which would do exactly what I moved 
into i915_gem_addr_unmap(), but there doesn't seem to be one.

+static inline void i915_gem_addr_unmap(void *mapped_addr)
+{
+	if (is_vmalloc_addr(mapped_addr))
+		vunmap(mapped_addr);
+	else
+		kunmap(kmap_to_page(mapped_addr));
+}

Do you think this would be of sufficient utility to be pushed upstream? 
The analogous kvfree() is quite widely used!

.Dave.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx