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. 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. Given all that I don't think this patch here is a blocker for doing other vma ops. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
