[PATCH 29/35] drm/amdgpu: svm bo enable_signal call condition
Christian König
christian.koenig at amd.com
Thu Jan 7 16:28:54 UTC 2021
Am 07.01.21 um 17:16 schrieb Felix Kuehling:
> Am 2021-01-07 um 5:56 a.m. schrieb Christian König:
>
>> Am 07.01.21 um 04:01 schrieb Felix Kuehling:
>>> From: Alex Sierra <alex.sierra at amd.com>
>>>
>>> [why]
>>> To support svm bo eviction mechanism.
>>>
>>> [how]
>>> If the BO crated has AMDGPU_AMDKFD_CREATE_SVM_BO flag set,
>>> enable_signal callback will be called inside amdgpu_evict_flags.
>>> This also causes gutting of the BO by removing all placements,
>>> so that TTM won't actually do an eviction. Instead it will discard
>>> the memory held by the BO. This is needed for HMM migration to user
>>> mode system memory pages.
>> I don't think that this will work. What exactly are you doing here?
> We discussed this a while ago when we talked about pipelined gutting.
> And you actually helped us out with a fix for that
> (https://patchwork.freedesktop.org/patch/379039/).
That's not what I meant. The pipelined gutting is ok, but why the
enable_signaling()?
Christian.
>
> SVM BOs are BOs in VRAM containing data for HMM ranges. When such a BO
> is evicted by TTM, we do an HMM migration of the data to system memory
> (triggered by kgd2kfd_schedule_evict_and_restore_process in patch 30).
> That means we don't need TTM to copy the BO contents to GTT any more.
> Instead we want to use pipelined gutting to allow the VRAM to be freed
> once the fence signals that the HMM migration is done (the
> dma_fence_signal call near the end of svm_range_evict_svm_bo_worker in
> patch 28).
>
> Regards,
> Felix
>
>
>> As Daniel pointed out HMM and dma_fences are fundamentally incompatible.
>>
>> Christian.
>>
>>> Signed-off-by: Alex Sierra <alex.sierra at amd.com>
>>> Signed-off-by: Felix Kuehling <Felix.Kuehling at amd.com>
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 ++++++++++++++
>>> 1 file changed, 14 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>> index f423f42cb9b5..62d4da95d22d 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>> @@ -107,6 +107,20 @@ static void amdgpu_evict_flags(struct
>>> ttm_buffer_object *bo,
>>> }
>>> abo = ttm_to_amdgpu_bo(bo);
>>> + if (abo->flags & AMDGPU_AMDKFD_CREATE_SVM_BO) {
>>> + struct dma_fence *fence;
>>> + struct dma_resv *resv = &bo->base._resv;
>>> +
>>> + rcu_read_lock();
>>> + fence = rcu_dereference(resv->fence_excl);
>>> + if (fence && !fence->ops->signaled)
>>> + dma_fence_enable_sw_signaling(fence);
>>> +
>>> + placement->num_placement = 0;
>>> + placement->num_busy_placement = 0;
>>> + rcu_read_unlock();
>>> + return;
>>> + }
>>> switch (bo->mem.mem_type) {
>>> case AMDGPU_PL_GDS:
>>> case AMDGPU_PL_GWS:
More information about the amd-gfx
mailing list