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