Puttin Marek on CC.

Am 27.05.21 um 03:30 schrieb Lang Yu:
To improve buffer migration performace, stop bookkeeping of
temporary GTT allocation, including allocation for BO evicted
from VRAM and bounce buffer.

Signed-off-by: Lang Yu <lang...@amd.com>
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 16 ++++++++++------
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c     |  4 +++-
  2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 8860545344c7..32fedd495c7f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -111,14 +111,15 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager 
*man,
        struct amdgpu_gtt_node *node;
        int r;
- spin_lock(&mgr->lock);
-       if ((&tbo->mem == mem || tbo->mem.mem_type != TTM_PL_TT) &&
-           atomic64_read(&mgr->available) < mem->num_pages) {
+       if (!(mem->placement & TTM_PL_FLAG_TEMPORARY)) {
+               spin_lock(&mgr->lock);
+               if (atomic64_read(&mgr->available) < mem->num_pages) {
+                       spin_unlock(&mgr->lock);
+                       return -ENOSPC;
+               }
+               atomic64_sub(mem->num_pages, &mgr->available);

After sleeping a night over that I think we need to talk about this part here once more.

While temporary GTT allocations can temporary exceed the GTT limitation we still need to account them in the case the eviction is interrupted for some reason.

In other words what can happen is that we want to move VRAM->GTT->SYSTEM, but GTT->SYSTEM never happens because it is interrupted in the wait (that's unfortunately rather likely).

To solve this I think we should do the following:
1. Change mgr->available into mgr->used (e.g. invert the value).
2. Always account all GTT BOs to the used space.
3. Only when it is not a temporary allocation bail out.

This way temporary allocations are accounted for, but we still allow memory evictions to happen under pressure.

While at it you could also drop taking the spinlock to check the atomic, that is pretty much unnecessary.

Regards,
Christian.

                spin_unlock(&mgr->lock);
-               return -ENOSPC;
        }
-       atomic64_sub(mem->num_pages, &mgr->available);
-       spin_unlock(&mgr->lock);
if (!place->lpfn) {
                mem->mm_node = NULL;
@@ -178,6 +179,9 @@ static void amdgpu_gtt_mgr_del(struct ttm_resource_manager 
*man,
                kfree(node);
        }
+ if (mem->placement & TTM_PL_FLAG_TEMPORARY)
+               return;
+
        atomic64_add(mem->num_pages, &mgr->available);
  }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index c0aef327292a..129d39392859 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -152,9 +152,11 @@ static void amdgpu_evict_flags(struct ttm_buffer_object 
*bo,
                        abo->placements[0].lpfn = 0;
                        abo->placement.busy_placement = &abo->placements[1];
                        abo->placement.num_busy_placement = 1;
+                       abo->placements[1].flags |= TTM_PL_FLAG_TEMPORARY;
                } else {
                        /* Move to GTT memory */
                        amdgpu_bo_placement_from_domain(abo, 
AMDGPU_GEM_DOMAIN_GTT);
+                       abo->placements[0].flags |= TTM_PL_FLAG_TEMPORARY;
                }
                break;
        case TTM_PL_TT:
@@ -538,7 +540,7 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo, 
bool evict,
                        hop->fpfn = 0;
                        hop->lpfn = 0;
                        hop->mem_type = TTM_PL_TT;
-                       hop->flags = 0;
+                       hop->flags |= TTM_PL_FLAG_TEMPORARY;
                        return -EMULTIHOP;
                }

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Reply via email to