[PATCH] drm/amdgpu: Adjust the VM size based on system memory size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 22.08.2018 um 19:40 schrieb Felix Kuehling:
> On 2018-08-22 02:55 AM, Christian König wrote:
>> Am 21.08.2018 um 23:45 schrieb Felix Kuehling:
> [snip]
>>> +    } else {
>>>> +        struct sysinfo si;
>>>> +        unsigned int phys_ram_gb;
>>>> +
>>>> +        /* Optimal VM size depends on the amount of physical
>>>> +         * RAM available. Underlying requirements and
>>>> +         * assumptions:
>>>> +         *
>>>> +         *  - Need to map system memory and VRAM from all GPUs
>>>> +         *     - VRAM from other GPUs not known here
>>>> +         *     - Assume VRAM <= system memory
>>>> +         *  - On GFX8 and older, VM space can be segmented for
>>>> +         *    different MTYPEs
>>>> +         *  - Need to allow room for fragmentation, guard pages etc.
>>>> +         */
>>>> +        si_meminfo(&si);
>>>> +        phys_ram_gb = ((uint64_t)si.totalram * si.mem_unit) >> 30;
>> Looks good to me, but I would make sure that round that up before
>> shifting it.
> Hmm, we used to round up. I just removed it because we were told it's
> not necessary.
>
> But I guess rounding up to the next power of two increases the available
> VM size without increasing page table size. So we should take it if we
> can get it for free. I'll reintroduce rounding up.

No, that wasn't what I meant. Rounding up to the next power of two is 
indeed not necessary.

What I meant is when the installed system memory is 3.9GB we only take 
into account 3GB here because we always truncate.

>>>> +        vm_size = min(max(phys_ram_gb * 3, min_vm_size), max_size);
>> Mhm, "phys_ram_gb * 3"? Maybe add a comment with the rational for that.
> Well, the long comment above was meant to justify the factor 3. Maybe I
> didn't make that clear enough. 1x is system memory itself, 2x is a wild
> guess of VRAM on all GPUs. 3x is room for a second aperture for MTYPE
> control, fragmentation and guard pages.

Ah! Yeah that wasn't obvious.

Christian.

>
> Regards,
>    Felix
>
>> Christian.
>>
>>>>        }
>>>>          adev->vm_manager.max_pfn = (uint64_t)vm_size << 18;
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
>>>> index 1162c2b..ab1d23e 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
>>>> @@ -345,7 +345,7 @@ struct amdgpu_bo_va_mapping
>>>> *amdgpu_vm_bo_lookup_mapping(struct amdgpu_vm *vm,
>>>>    void amdgpu_vm_bo_trace_cs(struct amdgpu_vm *vm, struct
>>>> ww_acquire_ctx *ticket);
>>>>    void amdgpu_vm_bo_rmv(struct amdgpu_device *adev,
>>>>                  struct amdgpu_bo_va *bo_va);
>>>> -void amdgpu_vm_adjust_size(struct amdgpu_device *adev, uint32_t
>>>> vm_size,
>>>> +void amdgpu_vm_adjust_size(struct amdgpu_device *adev, uint32_t
>>>> min_vm_size,
>>>>                   uint32_t fragment_size_default, unsigned max_level,
>>>>                   unsigned max_bits);
>>>>    int amdgpu_vm_ioctl(struct drm_device *dev, void *data, struct
>>>> drm_file *filp);
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux