[PATCH 1/2] drm/nouveau: move io_reserve_lru handling into the driver

[Christian König]

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
>