[PATCH 3/3] drm/amdgpu: add gtt_sys_limit

Felix Kuehling felix.kuehling at amd.com
Tue Jun 27 19:25:27 UTC 2017


On 17-06-27 04:01 AM, Christian König wrote:
> Am 27.06.2017 um 04:57 schrieb Michel Dänzer:
>> On 27/06/17 08:39 AM, John Brooks wrote:
>>> On Mon, Jun 26, 2017 at 03:39:57PM +0200, Christian König wrote:
>>>> From: Christian König <christian.koenig at amd.com>
>>>>
>>>> Limit the size of the GART table for the system domain.
>>>>
>>>> This saves us a bunch of visible VRAM, but also limitates the
>>>> maximum BO size we can swap out.
>>>>
>>>> Signed-off-by: Christian König <christian.koenig at amd.com>
>>> Hmm.
>>>
>>> On my system, GTT is 4096MiB (1048576 pages). For this, the table
>>> takes up
>>> 1048576*8 bytes = 8MiB. Reducing GTT to 256MiB (65536 pages) would
>>> reduce the
>>> size of the table to 512 KiB. A relatively large saving, to be sure.
>>> But in the
>>> grander scheme of things, is saving 7.5MiB (3% of visible VRAM @
>>> 256M) worth
>>> cutting GTT memory by a factor of 16?
>
> The amount of GTT memory the application can use through the VM page
> tables stays the same.
>
> Only the system VM is limited to 256MB and so saves us a whole bunch
> of space.
>
>> I'm afraid not, especially since it would limit the maximum BO size to <
>> 256MB, if I understand correctly. Pretty sure that would cause failures
>> with real world apps.
> Yes, exactly that's the major problem here. I should have put a WIP
> mark on the patch.

OK, I should adapt this for the KFD branch. Currently we make our GART
much bigger. On a system with lots of system memory, we can use up half
the visible VRAM for the GART. With something like this we can get it
back to something reasonable. But a 256MB limit on single allocation
size is definitely too small.

Also, if this breaks S3, we have to make sure the hybrid branches don't
pick it up accidentally.

Regards,
  Felix

>
> Christian.



More information about the amd-gfx mailing list