Am 26.03.2018 um 10:47 schrieb Chunming Zhou:
> From: Christian König <ckoenig.leichtzumerken at gmail.com>
>
> If a per VM BO ends up in a allowed domain it never moves back into the
> prefered domain.
>
> Change-Id: Ifb3e561785d3b464da28c439b271c26825224c5e
> Signed-off-by: Christian König <christian.koenig at amd.com>
> Reviewed-and-Tested-by: Chunming Zhou <david1.zhou at amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index e9a41dd05345..7db411a282ce 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -1808,14 +1808,16 @@ int amdgpu_vm_handle_moved(struct amdgpu_device *adev,
>
> spin_lock(&vm->status_lock);
> while (!list_empty(&vm->moved)) {
> - struct amdgpu_bo_va *bo_va;
> struct reservation_object *resv;
> + struct amdgpu_bo_va *bo_va;
> + struct amdgpu_bo *bo;
>
> bo_va = list_first_entry(&vm->moved,
> struct amdgpu_bo_va, base.vm_status);
> spin_unlock(&vm->status_lock);
>
> - resv = bo_va->base.bo->tbo.resv;
> + bo = bo_va->base.bo;
> + resv = bo->tbo.resv;
>
> /* Per VM BOs never need to bo cleared in the page tables */
> if (resv == vm->root.base.bo->tbo.resv)
> @@ -1835,6 +1837,15 @@ int amdgpu_vm_handle_moved(struct amdgpu_device *adev,
> kcl_reservation_object_unlock(resv);
>
> spin_lock(&vm->status_lock);
> +
> + /* If the BO prefers to be in VRAM, but currently isn't add it
> + * back to the evicted list so that it gets validated again on
> + * the next command submission.
> + */
> + if (resv == vm->root.base.bo->tbo.resv &&
> + bo->preferred_domains == AMDGPU_GEM_DOMAIN_VRAM &&
> + bo->tbo.mem.mem_type != TTM_PL_VRAM)
> + list_add_tail(&bo_va->base.vm_status, &vm->evicted);
Thinking about this more, might be even better to put that into
amdgpu_vm_bo_update() instead of the
"list_del_init(&bo_va->base.vm_status);".
I'm on easter vacation this week, so checking mails is delayed. But I'm
going to look at patch #2 this evening or tomorrow.
Regards,
Christian.
> }
> spin_unlock(&vm->status_lock);
>
