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