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(¶ms, owner, exclusive);
> if (r)
> - return r;
> + goto error_unlock;
>
> r = amdgpu_vm_update_ptes(¶ms, start, last + 1, addr, flags);
> if (r)
> - return r;
> + goto error_unlock;
>
> - return vm->update_funcs->commit(¶ms, fence);
> + r = vm->update_funcs->commit(¶ms, 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
next prev parent 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