On Tue, Apr 14, 2015 at 07:08:35PM +0200, Daniel Vetter wrote: > On Tue, Apr 14, 2015 at 05:12:30PM +0100, Chris Wilson wrote: > > On Tue, Apr 14, 2015 at 05:09:27PM +0100, Chris Wilson wrote: > > > On Tue, Apr 14, 2015 at 05:35:12PM +0200, Daniel Vetter wrote: > > > > They change with the address space and not with each vma, so move them > > > > into the right pile of vfuncs. Save 2 pointers per vma and clarifies > > > > the code. > > > > > > Using per-vma vfunc allows you make, for example, the pagetables > > > themselves an ordinary vma in the GGTT and so operate identically wrt to > > > the shrinker and eviction logic - removing some very fragile code in the > > > process. > > > > A vma->ops would be an interesting compromise. > > Tbh still not really sold on this idea, since the complexit tends to be in > the recursion. E.g. see all the fun we had with gpu_idle and the default > context. So for now I still prefer things to be explicit. Ah, you mean the fun that gpu_idle is broken at the moment. I think that lends weight to my argument tbh. > Also that would be a new op to first (try) to unuse the dma. If we don't > do this and it fails then the shrinker gets annoyed since the nice > hole-punching doesn't work correctly. There's also the fairness question, > we'd need to make sure that e.g. the hw context gets cycled through the > active list even when we don't switch contexts. Yes, all that was taken into account by my patches to sanitize request handling. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
