On Tue, Dec 20, 2016 at 01:38:16PM +0000, Tvrtko Ursulin wrote: > > On 20/12/2016 12:36, Chris Wilson wrote: > >On Tue, Dec 20, 2016 at 11:33:27AM +0000, Chris Wilson wrote: > >>On Tue, Dec 20, 2016 at 11:13:43AM +0000, Tvrtko Ursulin wrote: > >>>How much is the cost of freeing and re-acquiring pages in the fall > >>>back case? It could be avoidable by using the table and adding > >>>something like sgt = i915_sg_copy(sgt, table_max_segment). But it > >>>depends on how likely is this path to be hit on swiotlb platforms. I > >>>have no idea. Our datasets are much bigger than the swiotlb space - > >>>if that is true on such platforms? > >> > >>It's below my level of care (atm). Platforms hitting this are using > >>swiotlb *bounce* buffers. They will not be able to support a full gfx > >>workload and be going through a copy. We could avoid the additional > >>work, the sg_table is large enough for a 1:1 copy if we do it before the > >>trim, but more importantly we need a simple fix for 4.10. > > > >Pushed this pair as I think this is the safe course of action. Creating > >i915_sg_expand() is a job for a rainy day. > > It would have been very simple and much more elegant in my opinion. I'm ready to be impressed, in my head to do an inplace rewrite was tricky. :) > But I understand Tested-by tag was precious to keep. I'll send a > patch shortly but it won't be very tested due to time constraints. > > Also I don't know why you changed page_count and i to unsigned long > when the sg API can only handle unsigned int for that. Primary concern was moving them out of the way and worrying about our own 64bit object size issues. Hmm, can we reuse if (overflows_type(pgcount, unsigned int)) return -E2BIG; to catch the mismatch? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
