[Intel-gfx] [PATCH v2] drm/i915: Add ppgtt->kunmap_page_dma vfunc

[Chris Wilson]

On Wed, May 18, 2016 at 02:31:28PM +0100, Tvrtko Ursulin wrote:
> 
> On 18/05/16 13:22, Chris Wilson wrote:
> >Advantage: we avoid the clflush after every update
> >Disadvantage: we invoke set_memory_*() on every page used by the ppggtt.
> >(To reduce that cost, I have in made keeping a pagevec cache of WC
> >pages.)
> >
> >Sadly, we can't just use kmap_atomic_prot() as it is 32-bit only!!!
> >
> >Note that I started with exactly this patch (using a kunmap vfunc) many
> >moons ago and switched to the pgprot_t based approach instead.
> 
> The pattern of writes is such that write-combine makes a difference
> here versus an explicit flush? Taking into consideration the
> complexity of the pagevec cache you mention is required for the
> set_memory_wc route?

Yes, I think the WCB is the preferred path here (versus doing a sweep
over the whole page to clflush). Most frequent updates tends to be
framebuffers being passed between clients (since we close and unbind the
VMA every time) which are ~8 whole pages each. (We can expect to have
flush about 10 pages to misalignment, and so even if we were able to
match WC we still do 25% more clflushes).

It's not required for the set_memory_wc route, just will be a nice
addition. The principle issue should be fixed already in mm/vmalloc.c -
and note that we already have the issue with set_memory_uc/_wb being
invoked per context for no good reason.
 
> Many moons ago comment makes me think we could have at least had an
> inter-rim vfunc solution in place all this time.

Similarly there is a queue of patches to try and tackle some of the
regressions over the last couple of year that are now lost because no one
dares review them.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre