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@xxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
