Re: [PATCH 27/27] drm/amdgpu: Fix GTT size calculation

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

 



On 2019-04-30 5:32 a.m., Christian König wrote:
> [CAUTION: External Email]
>
> Am 30.04.19 um 01:16 schrieb Kuehling, Felix:
>> On 2019-04-29 8:34 a.m., Christian König wrote:
>>> Am 28.04.19 um 09:44 schrieb Kuehling, Felix:
>>>> From: Kent Russell <kent.russell@xxxxxxx>
>>>>
>>>> GTT size is currently limited to the minimum of VRAM size or 3/4 of
>>>> system memory. This severely limits the quanitity of system memory
>>>> that can be used by ROCm application.
>>>>
>>>> Increase GTT size to the maximum of VRAM size or system memory size.
>>> Well, NAK.
>>>
>>> This limit was done on purpose because we otherwise the
>>> max-texture-size would be crashing the system because the OOM killer
>>> would be causing a system panic.
>>>
>>> Using more than 75% of system memory by the GPU at the same time makes
>>> the system unstable and so we can't allow that by default.
>> Like we discussed, the current implementation is too limiting. On a Fiji
>> system with 4GB VRAM and 32GB system memory, it limits system memory
>> allocations to 4GB. I think this workaround was fixed once before and
>> reverted because it broke a CZ system with 1GB system memory. So I
>> suspect that this is an issue affecting small memory systems where maybe
>> the 1/2 system memory limit in TTM isn't sufficient to protect from OOM
>> panics.
>
> Well it not only broke on a 1GB CZ system, this was just where Andrey
> reproduced it. We got reports from all kind of systems.

I'd like to see those reports. This patch has been included in Linux Pro 
releases since 18.20. I'm not aware that anyone complained about it.


>
>> The OOM killer problem is a more general problem that potentially
>> affects other drivers too. Keeping this GTT limit broken in AMDGPU is an
>> inadequate workaround at best. I'd like to look for a better solution,
>> probably some adjustment of the TTM system memory limits on systems with
>> small memory, to avoid OOM panics on such systems.
>
> The core problem here is that the OOM killer explicitly doesn't want to
> block for shaders to finish whatever it is doing.
>
> So currently as soon as the hardware is using some memory it can't be
> reclaimed immediately.
>
> The original limit in TTM was 2/3 of system memory and that worked
> really reliable and we ran into problems only after raising it to 3/4.

The TTM system memory limit is still 3/8 soft and 1/2 hard, 3/4 for 
emergencies. See ttm_mem_init_kernel_zone. AFAICT, the emergency limit 
is only available to root.

This GTT limit kicks in before I get anywhere close to the TTM limit. 
That's why I think it is both broken and redundant.


>
> To sum it up the requirement of using almost all system memory by a GPU
> is simply not possible upstream and even in any production system rather
> questionable.

It should be doable with userptr, which now uses unpinned pages through 
HMM. Currently the GTT limit affects the largest possible userptr 
allocation, though not the total sum of all userptr allocations. Maybe 
making userptr completely independent of GTT size would be an easier 
problem to tackle. Then I can leave the GTT limit alone.


>
> The only real solution I can see is to be able to reliable kill shaders
> in an OOM situation.

Well, we can in fact preempt our compute shaders with low latency. 
Killing a KFD process will do exactly that.

Regards,
   Felix


>
> Regards,
> Christian.
>
>>
>> Regards,
>>     Felix
>>
>>
>>> What could maybe work is to reduce amount of system memory by a fixed
>>> factor, but I of hand don't see a way of fixing this in general.
>>>
>>> Regards,
>>> Christian.
>>>
>>>> Signed-off-by: Kent Russell <kent.russell@xxxxxxx>
>>>> Reviewed-by: Felix Kuehling <Felix.Kuehling@xxxxxxx>
>>>> Signed-off-by: Felix Kuehling <Felix.Kuehling@xxxxxxx>
>>>> ---
>>>>    drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 9 ++++-----
>>>>    1 file changed, 4 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>>> index c14198737dcd..e9ecc3953673 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>>>> @@ -1740,11 +1740,10 @@ int amdgpu_ttm_init(struct amdgpu_device 
>>>> *adev)
>>>>            struct sysinfo si;
>>>>              si_meminfo(&si);
>>>> -        gtt_size = min(max((AMDGPU_DEFAULT_GTT_SIZE_MB << 20),
>>>> -                   adev->gmc.mc_vram_size),
>>>> -                   ((uint64_t)si.totalram * si.mem_unit * 3/4));
>>>> -    }
>>>> -    else
>>>> +        gtt_size = max3((AMDGPU_DEFAULT_GTT_SIZE_MB << 20),
>>>> +                adev->gmc.mc_vram_size,
>>>> +                ((uint64_t)si.totalram * si.mem_unit));
>>>> +    } else
>>>>            gtt_size = (uint64_t)amdgpu_gtt_size << 20;
>>>>          /* Initialize GTT memory pool */
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@xxxxxxxxxxxxxxxxxxxxx
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
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