[PATCH] drm/amdkfd: Get prange->offset after svm_range_vram_node_new

Chen, Xiaogang xiaogang.chen at amd.com
Wed Mar 8 18:39:30 UTC 2023


On 3/8/2023 11:11 AM, Felix Kuehling wrote:
> On 2023-03-08 02:45, Xiaogang.Chen wrote:
>> From: Xiaogang Chen <xiaogang.chen at amd.com>
>>
>> During miration to vram prange->offset is valid after vram buffer is 
>> located,
>> either use old one or allocate a new one. Move 
>> svm_range_vram_node_new before migrate
>> for each vma to get valid prange->offset.
>>
>> Signed-off-by: Xiaogang Chen <Xiaogang.Chen at amd.com>
>
> I'd  prefer to keep svm_range_vram_node_new in 
> svm_migrate_copy_to_vram. Logically the memory allocation should be 
> after migrate_vma_setup. If migrate_vma_setup finds that there is 
> nothing to migrate, we should not allocate any memory.
>
> Does this fix a real issue, or is this a theoretical fix? I think it 
> should probably work correctly without this patch. 
> svm_range_vram_node_new sets prange->offset to 0. If no VRAM was 
> previously allocated, it should already be 0, so nothing changes. 
> Maybe we just need a fix to set prange->offset = 0 in 
> svm_range_vram_node_free.

A real issue is same prange migrate vram->cpu, then cpu->vram. During 
vram->cpu pragne got split, so prange->offset got changed, then vram 
node got freed by svm_range_vram_node_free, but not update 
prange->offset. It is the case KFDSVMRangeTes.MigrateTest. I will check 
by set prange->offset = 0 at svm_range_vram_node_free.

In theory, getting prange->offset after svm_range_vram_node_new makes 
code logically clearer? svm_range_vram_node_new handles different cases, 
we are not sure what prange->offset would be before call it.

If migrate_vma_setup fail for a vma, we can svm_range_vram_node_free the 
vram buffer got from svm_range_vram_node_new.

>
> Regards,
>   Felix
>
>
>> ---
>>   drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 12 ++++++------
>>   1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c 
>> b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
>> index fd54a00e7229..15791490c23e 100644
>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
>> @@ -310,12 +310,6 @@ svm_migrate_copy_to_vram(struct amdgpu_device 
>> *adev, struct svm_range *prange,
>>       src = scratch;
>>       dst = (uint64_t *)(scratch + npages);
>>   -    r = svm_range_vram_node_new(adev, prange, true);
>> -    if (r) {
>> -        dev_dbg(adev->dev, "fail %d to alloc vram\n", r);
>> -        goto out;
>> -    }
>> -
>>       amdgpu_res_first(prange->ttm_res, ttm_res_offset,
>>                npages << PAGE_SHIFT, &cursor);
>>       for (i = j = 0; i < npages; i++) {
>> @@ -525,6 +519,12 @@ svm_migrate_ram_to_vram(struct svm_range 
>> *prange, uint32_t best_loc,
>>         start = prange->start << PAGE_SHIFT;
>>       end = (prange->last + 1) << PAGE_SHIFT;
>> +
>> +    r = svm_range_vram_node_new(adev, prange, true);
>> +    if (r) {
>> +        dev_dbg(adev->dev, "fail %d to alloc vram\n", r);
>> +        return r;
>> +    }
>>       ttm_res_offset = prange->offset << PAGE_SHIFT;
>>         for (addr = start; addr < end;) {


More information about the amd-gfx mailing list