[Intel-gfx] [PATCH 02/17] drm/i915: Move vma vfuns to adddress_space
Chris Wilson
chris at chris-wilson.co.uk
Tue Apr 14 10:23:30 PDT 2015
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
More information about the Intel-gfx
mailing list