[PATCH 1/3] drm/amdgpu: Add userptr bo support for mGPUs when iommu is on
Felix Kuehling
felix.kuehling at amd.com
Wed Apr 12 14:29:28 UTC 2023
Am 2023-04-12 um 09:35 schrieb Philip Yang:
>
> On 2023-04-04 09:45, Felix Kuehling wrote:
>> [+Philip]
>>
>> Am 2023-04-04 um 08:47 schrieb Christian König:
>>
>>> Am 04.04.23 um 12:56 schrieb Xiao, Shane:
>>>> [AMD Official Use Only - General]
>>>>
>>>>> -----Original Message-----
>>>>> From: Koenig, Christian <Christian.Koenig at amd.com>
>>>>> Sent: Tuesday, April 4, 2023 6:27 PM
>>>>> To: Xiao, Shane <shane.xiao at amd.com>; amd-gfx at lists.freedesktop.org;
>>>>> Kuehling, Felix <Felix.Kuehling at amd.com>
>>>>> Cc: Liu, Aaron <Aaron.Liu at amd.com>; Guo, Shikai <Shikai.Guo at amd.com>
>>>>> Subject: Re: [PATCH 1/3] drm/amdgpu: Add userptr bo support for mGPUs
>>>>> when iommu is on
>>>>>
>>>>> Am 04.04.23 um 11:56 schrieb Shane Xiao:
>>>>>> For userptr bo with iommu on, multiple GPUs use same system
>>>>>> memory dma
>>>>>> mapping address when both bo_adev and adev in identity mode or in
>>>>>> the
>>>>>> same iommu group.
>>>> Hi Christian,
>>>>
>>>>> WTF? Userptr BOs are not allowed to be exported/imported between
>>>>> different
>>>>> GPUs.
>>>>>
>>>>> So how can the same userptr BO be used on different GPUs?
>>>> If GPUs are all in iommu identity mode which means dma address are
>>>> the same as physical address, all of the GPUs can see the system
>>>> memory directly.
>>>>
>>>> In such case, should we export/import the BO, then create a new SG
>>>> BO for another GPU?
>>>
>>> Yes, absolutely. Each userptr BO is only meant to be used on one GPU.
>>>
>>> Even if you could use the same BO for multiple GPUs it's not
>>> necessary a good idea since you then have live time problems for
>>> example.
>>>
>>> E.g. what happens when one GPU is hot removed while the other one
>>> who imported the BO is still in use?
>>>
>>> Felix can you comment on that? My recollection was that we rather
>>> improve the storage of DMA addresses instead of duplicating the BOs
>>> over different GPUs.
>>
>> For KFD we currently enable sharing of userptr BOs between multiple
>> GPUs by creating a userptr BO for the first GPU, and creating
>> additional SG BOs using the same page list for additional GPUs. That
>> way we don't have to call hmm_range_fault N times and setup N MMU
>> notifiers for the same address range on an N GPU system. But we do
>> have to create N DMA mappings, which is facilitated by the SG BOs.
>>
>> We have a further optimization to not even store separate DMA
>> addresses per-GPU if they are a direct mapping. In that case we just
>> increase the reference count on the original userptr BO. (I agree
>> that we should also look into more efficient storage of DMA
>> addresses. However, last time we talked about this, you basically
>> told us that scatter gather tables are being deprecated, but I
>> haven't seen the alternative yet.)
>>
>> I think this patch fixes a potential issue with that optimization.
>> There is an implicit assumption, that the DMA addresses stored in the
>> original userptr BO are a direct mapping, so we can reuse them on
>> other GPUs that also use a direct mapping. But, we didn't actually
>> check that assumption. I think this patch fixes that for systems
>> where system memory is direct mapped on some but not all GPUs.
>
> We will need similar optimization in svm_range_dma_map to reuse the
> prange->dma_addr for GPUs on same iommu group or direct mapping.
Good point. Optimizing for direct mapping is easy: Just skip the dmamap.
Reusing the same dmamapping for multiple GPUs in the same IOMMU group is
a bit harder. First you need to identify all the GPUs that are in the
same group and then check if one of them already has a DMA mapping that
can be reused. I wonder how common this is, and whether it's worth the
trouble.
Regards,
Felix
>
> Regards,
>
> Philip
>
>>
>> This scenario should probably be called out explicitly in the patch
>> description. The condition is also getting pretty hard to read and
>> understand. Maybe move the both-direct-map-or-same-iommu-group
>> conditions into a helper function, say
>> "amdgpu_ttm_tt_get_usermm(mem->bo->tbo.ttm) && reuse_dmamap(adev,
>> bo_adev)".
>>
>> Regards,
>> Felix
>>
>>
>>>
>>> Regards,
>>> Christian.
>>>
>>>>
>>>>
>>>> Best Regards,
>>>> Shane
>>>>
>>>>> Regards,
>>>>> Christian.
>>>>>
>>>>>> Signed-off-by: Shane Xiao <shane.xiao at amd.com>
>>>>>> ---
>>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 ++++----
>>>>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>>>>>> index e7403f8e4eba..33cda358cb9e 100644
>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>>>>>> @@ -804,11 +804,11 @@ static int kfd_mem_attach(struct amdgpu_device
>>>>> *adev, struct kgd_mem *mem,
>>>>>> va + bo_size, vm);
>>>>>>
>>>>>> if ((adev == bo_adev && !(mem->alloc_flags &
>>>>> KFD_IOC_ALLOC_MEM_FLAGS_MMIO_REMAP)) ||
>>>>>> - (amdgpu_ttm_tt_get_usermm(mem->bo->tbo.ttm) &&
>>>>> adev->ram_is_direct_mapped) ||
>>>>>> - same_hive) {
>>>>>> + (amdgpu_ttm_tt_get_usermm(mem->bo->tbo.ttm) &&
>>>>> ((adev->ram_is_direct_mapped && bo_adev->ram_is_direct_mapped) ||
>>>>>> + adev->dev->iommu_group == bo_adev->dev-
>>>>>> iommu_group)) ||
>>>>>> +same_hive){
>>>>>> /* Mappings on the local GPU, or VRAM mappings in
>>>>> the
>>>>>> - * local hive, or userptr mapping IOMMU direct map
>>>>> mode
>>>>>> - * share the original BO
>>>>>> + * local hive, or userptr mapping in the same dma
>>>>>> + * address space share the original BO
>>>>>> */
>>>>>> attachment[i]->type = KFD_MEM_ATT_SHARED;
>>>>>> bo[i] = mem->bo;
>>>
More information about the amd-gfx
mailing list