Re: [RFC 00/22] Gen7 batch buffer command parser

["Volkin, Bradley D" <bradley.d.volkin@intel.com>]

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