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.
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.
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.
Regards, Christian.
-Daniel
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
