AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Felix Kuehling <felix.kuehling@amd.com>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
	amd-gfx@lists.freedesktop.org, philip.yang@amd.com,
	Alex.Sierra@amd.com
Subject: Re: [PATCH 4/5] drm/amdgpu: add VM eviction lock v2
Date: Thu, 5 Dec 2019 11:33:45 -0500	[thread overview]
Message-ID: <3111c8dc-fe18-fa94-72fd-41624bf4b0bf@amd.com> (raw)
In-Reply-To: <20191205133940.3865-4-christian.koenig@amd.com>

On 2019-12-05 8:39 a.m., Christian König wrote:
> This allows to invalidate VM entries without taking the reservation lock.
>
> Signed-off-by: Christian König <christian.koenig@amd.com>
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 39 +++++++++++++++++++++-----
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  4 +++
>   2 files changed, 36 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index 0d700e8154c4..839d6df394fc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -656,7 +656,7 @@ int amdgpu_vm_validate_pt_bos(struct amdgpu_device *adev, struct amdgpu_vm *vm,
>   			      void *param)
>   {
>   	struct amdgpu_vm_bo_base *bo_base, *tmp;
> -	int r = 0;
> +	int r;
>   
>   	vm->bulk_moveable &= list_empty(&vm->evicted);
>   
> @@ -665,7 +665,7 @@ int amdgpu_vm_validate_pt_bos(struct amdgpu_device *adev, struct amdgpu_vm *vm,
>   
>   		r = validate(param, bo);
>   		if (r)
> -			break;
> +			return r;
>   
>   		if (bo->tbo.type != ttm_bo_type_kernel) {
>   			amdgpu_vm_bo_moved(bo_base);
> @@ -678,7 +678,11 @@ int amdgpu_vm_validate_pt_bos(struct amdgpu_device *adev, struct amdgpu_vm *vm,
>   		}
>   	}
>   
> -	return r;
> +	mutex_lock(&vm->eviction_lock);
> +	vm->evicting = false;
> +	mutex_unlock(&vm->eviction_lock);
> +
> +	return 0;
>   }
>   
>   /**
> @@ -1555,15 +1559,25 @@ static int amdgpu_vm_bo_update_mapping(struct amdgpu_device *adev,
>   	if (!(flags & AMDGPU_PTE_VALID))
>   		owner = AMDGPU_FENCE_OWNER_KFD;
>   
> +	mutex_lock(&vm->eviction_lock);
> +	if (vm->evicting) {
> +		r = EINPROGRESS;

Not sure about this error code. As far as I can find, this is normally 
used on non-blocking sockets. I found this explanation: 
https://stackoverflow.com/questions/8277970/what-are-possible-reason-for-socket-error-einprogress-in-solaris

Quote: "so there is another error for non-blocking connect: EINPROGRESS, 
which tells you that the operation is in progress and you should check 
its status later."

This call is neither non-blocking nor is the requested page table update 
in progress when this error is returned. So I'd think a better error to 
return here would be EBUSY.

Other than that, this patch is

Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>


> +		goto error_unlock;
> +	}
> +
>   	r = vm->update_funcs->prepare(&params, owner, exclusive);
>   	if (r)
> -		return r;
> +		goto error_unlock;
>   
>   	r = amdgpu_vm_update_ptes(&params, start, last + 1, addr, flags);
>   	if (r)
> -		return r;
> +		goto error_unlock;
>   
> -	return vm->update_funcs->commit(&params, fence);
> +	r = vm->update_funcs->commit(&params, fence);
> +
> +error_unlock:
> +	mutex_unlock(&vm->eviction_lock);
> +	return r;
>   }
>   
>   /**
> @@ -2522,11 +2536,19 @@ bool amdgpu_vm_evictable(struct amdgpu_bo *bo)
>   	if (!dma_resv_test_signaled_rcu(bo->tbo.base.resv, true))
>   		return false;
>   
> +	/* Try to block ongoing updates */
> +	if (!mutex_trylock(&bo_base->vm->eviction_lock))
> +		return false;
> +
>   	/* Don't evict VM page tables while they are updated */
>   	if (!dma_fence_is_signaled(bo_base->vm->last_direct) ||
> -	    !dma_fence_is_signaled(bo_base->vm->last_delayed))
> +	    !dma_fence_is_signaled(bo_base->vm->last_delayed)) {
> +		mutex_unlock(&bo_base->vm->eviction_lock);
>   		return false;
> +	}
>   
> +	bo_base->vm->evicting = true;
> +	mutex_unlock(&bo_base->vm->eviction_lock);
>   	return true;
>   }
>   
> @@ -2773,6 +2795,9 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct amdgpu_vm *vm,
>   	vm->last_direct = dma_fence_get_stub();
>   	vm->last_delayed = dma_fence_get_stub();
>   
> +	mutex_init(&vm->eviction_lock);
> +	vm->evicting = false;
> +
>   	amdgpu_vm_bo_param(adev, vm, adev->vm_manager.root_level, false, &bp);
>   	if (vm_context == AMDGPU_VM_CONTEXT_COMPUTE)
>   		bp.flags &= ~AMDGPU_GEM_CREATE_SHADOW;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> index d93ea9ad879e..d5613d184e99 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> @@ -242,6 +242,10 @@ struct amdgpu_vm {
>   	/* tree of virtual addresses mapped */
>   	struct rb_root_cached	va;
>   
> +	/* Lock to prevent eviction while we are updating page tables */
> +	struct mutex		eviction_lock;
> +	bool			evicting;
> +
>   	/* BOs who needs a validation */
>   	struct list_head	evicted;
>   
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  reply	other threads:[~2019-12-05 16:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-05 13:39 [PATCH 1/5] drm/amdgpu: move VM eviction decision into amdgpu_vm.c Christian König
2019-12-05 13:39 ` [PATCH 2/5] drm/amdgpu: explicitely sync to VM updates v2 Christian König
2019-12-05 16:34   ` Felix Kuehling
2019-12-05 13:39 ` [PATCH 3/5] drm/amdgpu: stop adding VM updates fences to the resv obj Christian König
2019-12-05 16:43   ` Felix Kuehling
2019-12-05 13:39 ` [PATCH 4/5] drm/amdgpu: add VM eviction lock v2 Christian König
2019-12-05 16:33   ` Felix Kuehling [this message]
2019-12-05 13:39 ` [PATCH 5/5] drm/amdgpu: immedially invalidate PTEs Christian König
2019-12-05 16:45   ` Felix Kuehling
2019-12-05 17:15     ` Christian König
2019-12-12  0:20   ` Felix Kuehling
2019-12-12  8:51     ` Christian König
2019-12-12 14:38       ` Philip Yang
2019-12-12 15:12         ` Christian König
2020-01-03  4:20       ` Sierra Guiza, Alejandro (Alex)
2020-01-04 16:03         ` Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3111c8dc-fe18-fa94-72fd-41624bf4b0bf@amd.com \
    --to=felix.kuehling@amd.com \
    --cc=Alex.Sierra@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=philip.yang@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox