From: "Christian König" <christian.koenig@amd.com>
To: Qiang Yu <qiang.yu@amd.com>,
Alex Deucher <alexander.deucher@amd.com>,
"Pan, Xinhui" <Xinhui.Pan@amd.com>,
David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
Sumit Semwal <sumit.semwal@linaro.org>
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
linaro-mm-sig@lists.linaro.org
Subject: Re: [PATCH] drm/amdgpu: check vm bo eviction valuable at last
Date: Thu, 17 Feb 2022 10:15:22 +0100 [thread overview]
Message-ID: <5d3fdd2c-e74a-49f4-2b28-32c06483236f@amd.com> (raw)
In-Reply-To: <20220217090440.4468-1-qiang.yu@amd.com>
Am 17.02.22 um 10:04 schrieb Qiang Yu:
> Workstation application ANSA/META get this error dmesg:
> [drm:amdgpu_gem_va_ioctl [amdgpu]] *ERROR* Couldn't update BO_VA (-16)
>
> This is caused by:
> 1. create a 256MB buffer in invisible VRAM
> 2. CPU map the buffer and access it causes vm_fault and try to move
> it to visible VRAM
> 3. force visible VRAM space and traverse all VRAM bos to check if
> evicting this bo is valuable
> 4. when checking a VM bo (in invisible VRAM), amdgpu_vm_evictable()
> will set amdgpu_vm->evicting, but latter due to not in visible
> VRAM, won't really evict it so not add it to amdgpu_vm->evicted
> 5. before next CS to clear the amdgpu_vm->evicting, user VM ops
> ioctl will pass amdgpu_vm_ready() (check amdgpu_vm->evicted)
> but fail in amdgpu_vm_bo_update_mapping() (check
> amdgpu_vm->evicting) and get this error log
>
> This error won't affect functionality as next CS will finish the
> waiting VM ops. But we'd better make the amdgpu_vm->evicting
> correctly reflact the vm status and clear the error log.
Well NAK, that is intentional behavior.
The VM page tables where considered for eviction, so setting the flag is
correct even when the page tables later on are not actually evicted.
What we should rather do is to fix amdgpu_vm_ready() to take a look at
the flag instead of the linked list.
Regards,
Christian.
>
> Signed-off-by: Qiang Yu <qiang.yu@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 85 ++++++++++++++-----------
> 1 file changed, 47 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 5a32ee66d8c8..88a27911054f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -1306,45 +1306,11 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device *adev, struct ttm_tt *ttm,
> return flags;
> }
>
> -/*
> - * amdgpu_ttm_bo_eviction_valuable - Check to see if we can evict a buffer
> - * object.
> - *
> - * Return true if eviction is sensible. Called by ttm_mem_evict_first() on
> - * behalf of ttm_bo_mem_force_space() which tries to evict buffer objects until
> - * it can find space for a new object and by ttm_bo_force_list_clean() which is
> - * used to clean out a memory space.
> - */
> -static bool amdgpu_ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
> - const struct ttm_place *place)
> +static bool amdgpu_ttm_mem_eviction_valuable(struct ttm_buffer_object *bo,
> + const struct ttm_place *place)
> {
> unsigned long num_pages = bo->resource->num_pages;
> struct amdgpu_res_cursor cursor;
> - struct dma_resv_list *flist;
> - struct dma_fence *f;
> - int i;
> -
> - /* Swapout? */
> - if (bo->resource->mem_type == TTM_PL_SYSTEM)
> - return true;
> -
> - if (bo->type == ttm_bo_type_kernel &&
> - !amdgpu_vm_evictable(ttm_to_amdgpu_bo(bo)))
> - return false;
> -
> - /* If bo is a KFD BO, check if the bo belongs to the current process.
> - * If true, then return false as any KFD process needs all its BOs to
> - * be resident to run successfully
> - */
> - flist = dma_resv_shared_list(bo->base.resv);
> - if (flist) {
> - for (i = 0; i < flist->shared_count; ++i) {
> - f = rcu_dereference_protected(flist->shared[i],
> - dma_resv_held(bo->base.resv));
> - if (amdkfd_fence_check_mm(f, current->mm))
> - return false;
> - }
> - }
>
> switch (bo->resource->mem_type) {
> case AMDGPU_PL_PREEMPT:
> @@ -1377,10 +1343,53 @@ static bool amdgpu_ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
> return false;
>
> default:
> - break;
> + return ttm_bo_eviction_valuable(bo, place);
> }
> +}
>
> - return ttm_bo_eviction_valuable(bo, place);
> +/*
> + * amdgpu_ttm_bo_eviction_valuable - Check to see if we can evict a buffer
> + * object.
> + *
> + * Return true if eviction is sensible. Called by ttm_mem_evict_first() on
> + * behalf of ttm_bo_mem_force_space() which tries to evict buffer objects until
> + * it can find space for a new object and by ttm_bo_force_list_clean() which is
> + * used to clean out a memory space.
> + */
> +static bool amdgpu_ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
> + const struct ttm_place *place)
> +{
> + struct dma_resv_list *flist;
> + struct dma_fence *f;
> + int i;
> +
> + /* Swapout? */
> + if (bo->resource->mem_type == TTM_PL_SYSTEM)
> + return true;
> +
> + /* If bo is a KFD BO, check if the bo belongs to the current process.
> + * If true, then return false as any KFD process needs all its BOs to
> + * be resident to run successfully
> + */
> + flist = dma_resv_shared_list(bo->base.resv);
> + if (flist) {
> + for (i = 0; i < flist->shared_count; ++i) {
> + f = rcu_dereference_protected(flist->shared[i],
> + dma_resv_held(bo->base.resv));
> + if (amdkfd_fence_check_mm(f, current->mm))
> + return false;
> + }
> + }
> +
> + /* Check by different mem type. */
> + if (!amdgpu_ttm_mem_eviction_valuable(bo, place))
> + return false;
> +
> + /* VM bo should be checked at last because it will mark VM evicting. */
> + if (bo->type == ttm_bo_type_kernel)
> + return amdgpu_vm_evictable(ttm_to_amdgpu_bo(bo));
> +
> + return true;
> }
>
> static void amdgpu_ttm_vram_mm_access(struct amdgpu_device *adev, loff_t pos,
next prev parent reply other threads:[~2022-02-17 9:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-17 9:04 [PATCH] drm/amdgpu: check vm bo eviction valuable at last Qiang Yu
2022-02-17 9:15 ` Christian König [this message]
2022-02-17 9:40 ` Qiang Yu
2022-02-17 9:46 ` Christian König
2022-02-17 10:13 ` Qiang Yu
2022-02-17 10:39 ` Christian König
2022-02-17 10:58 ` Qiang Yu
2022-02-17 12:22 ` Christian König
2022-02-18 3:08 ` Qiang Yu
2022-02-18 7:46 ` Christian König
2022-02-18 8:58 ` Qiang Yu
2022-02-18 9:27 ` Christian König
2022-02-18 10:16 ` Qiang Yu
2022-02-18 10:24 ` Christian König
2022-02-21 3:28 ` Qiang Yu
2022-02-21 8:24 ` 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=5d3fdd2c-e74a-49f4-2b28-32c06483236f@amd.com \
--to=christian.koenig@amd.com \
--cc=Xinhui.Pan@amd.com \
--cc=airlied@linux.ie \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=qiang.yu@amd.com \
--cc=sumit.semwal@linaro.org \
/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