On Thu, Oct 10, 2019 at 9:54 AM Christian König
<ckoenig.leichtzumerken@xxxxxxxxx> wrote:
>
> Am 09.10.19 um 17:39 schrieb Daniel Vetter:
> > On Mon, Sep 30, 2019 at 03:12:53PM +0200, Christian König wrote:
> > [SNIP]
> >> +static vm_fault_t nouveau_ttm_fault(struct vm_fault *vmf)
> >> +{
> >> + struct vm_area_struct *vma = vmf->vma;
> >> + struct ttm_buffer_object *bo = vma->vm_private_data;
> >> + pgprot_t prot;
> >> + vm_fault_t ret;
> >> +
> >> + ret = ttm_bo_vm_reserve(bo, vmf);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + nouveau_bo_del_io_reserve_lru(bo);
> > Isn't this opening up a can of worms (in theory) where a lot of concurrent
> > faults will all fail because they're all removed themselves from the lru,
> > so can't see anyone else to throw out?
> >
> > Same problem really that ttm had (well still has I think for !amdgpu) with
> > its other lru ...
> >
> > Or am I getting totally lost again here?
>
> No, your are pretty much correct. But we are not opening up that can of
> worms, it has been here for like always.
Ah, I didn't check the ttm-based version closely enough to convince
myself it has the same problem.
> You just need to imagine that you have two processes kicking out the
> page tables of each other before somebody had a chance to make progress.
> This will just loop forever :)
>
> The correct solution is to not use a BO based approach at all, but
> rather a window based approach where you have an LRU of the window you
> gave out last to access something. This way you have a much larger
> number of windows you can use (4k if you use 64kB window size on a 256MB
> BAR).
>
> This way you can safely assume that the number of windows you have
> available is always larger than the number of faults you can process at
> the same time. But that would require quite a bunch of changes for TTM
> as well as nouveau.
Yeah we do that on i915 since a while, buffers became way too big.
Somewhat tricky on older hw where we also detile, there the window we
pick needs to be at least a full tile row.
> BTW: This is one of the reasons (additional to that it is horrible slow)
> why we never used the remapping feature on AMD hardware for Linux.
Not feeling like a full r-b, and you definitely want someone to test
this on nouveau, but at leat
Acked-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
for the series.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
