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. > 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. -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
