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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
