On Wed, Dec 11, 2013 at 01:54:40AM -0800, Daniel Vetter wrote: > On Tue, Dec 10, 2013 at 04:58:18PM -0800, Volkin, Bradley D wrote: > > So, I have a functioning kmap_atomic based parser using an sg_mapping_iter, and in the > > tests I'm running, it's worse than the vmap approach. This is still without the batch > > copy, but I think it's relevant anyhow. I haven't done much in the way of analysis as to > > why we're getting these results. At a high level, the vmap approach leads to simple > > code with a few function calls and control structures. The per-page approach has > > somewhat more complex logic around mapping the next page at the right time and checking > > for commands that cross a page boundary. I'd guess that difference factors into it. > > > > Due to the risk of regressions, I think it would be better not to delay getting > > broader functional and performance testing by waiting to sort this out. I'd rather > > stick with vmap for now and revisit that overhead once we have more concrete > > performance data to work from. > > Yeah, makes sense. Just to check: Was that on hsw with llc coherency or on > vlv? Might be that the clflushing shifts the picture around a bit. IVB and HSW. There's now a wait_rendering() call that should cover the gem_cpu_reloc case. I haven't had a chance to go back and test on VLV to see if the clflushing helps with the other coherency issue. > > > I'll propose that I send an updated series later this week or next that addresses > > feedback from the review, including better handling for secure and chained batches, > > the sync fixes for gem_cpu_reloc, some of the additional tests you suggested, > > and possibly an attempt at batch copy. If that goes well, could we see about > > getting the patches into the hands of your QA team for further testing? > > We unfortunately don't really have tons of spare cycles from our QA team > for testing branches (pretty much none actually), so the usual approach is > to review and merge patches without first going through QA. If we pull in > your new i-g-ts first we should have decent assurance that nothing blows > up. And since kernel patch series should always be fully bisectable we can > stop at any point in time if something goes wrong. Ok, sounds good. I'm fine with whatever approach gets us the test coverage soonest. Brad > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
