[PATCH v3] drm/amdgpu: Add debugfs entry for printing VM info

Christian König christian.koenig at amd.com
Mon Oct 12 10:50:01 UTC 2020


Am 12.10.20 um 12:00 schrieb Patel, Mihir:
> [AMD Official Use Only - Internal Distribution Only]
>
>
>
> -----Original Message-----
> From: Koenig, Christian <Christian.Koenig at amd.com>
> Sent: Monday, October 12, 2020 3:14 PM
> To: Patel, Mihir <Mihir.Patel at amd.com>; amd-gfx at lists.freedesktop.org
> Cc: Chauhan, Madhav <Madhav.Chauhan at amd.com>; Deucher, Alexander <Alexander.Deucher at amd.com>; Surampalli, Kishore <Kishore.Surampalli at amd.com>; Kamliya, Prakash <Prakash.Kamliya at amd.com>
> Subject: Re: [PATCH v3] drm/amdgpu: Add debugfs entry for printing VM info
>
> [SNIP]
>> Hi Christian,
>> One question regarding getting total allocations by app and also swapped size for the app.
>> Shouldn’t we print mapped entries as well to get total allocation by the process ?
>> Also which list would represent swapped memory?
> None, we don't really have that information anywhere since we don't really have a swapped state.
>
> See when the application allocates a BO in VRAM the kernel driver is free to swap it out to GTT and still do command submission. Only when it is further swapped out to the CPU domain it is not accessible any more.
>
> So what you can do is to look at the BOs in the CPU domain, but this only gives you a certain hint on what's going on.
>
> Regards,
> Christian.
>
> Thanks Christian for clarifying about swapped memory. How about total allocated size? Can't we print mapped BOs since amdgpu_gem_info is FILE/gem handle based?

That's what you are already printing. E.g. if you sum up all the BOs in 
all the different states then you have the total amount of allocated 
memory for this process.

Even if some of that memory isn't mapped into the VM.

Christian.

> Regards,
> Mihir
>> Thanks,
>> Mihir



More information about the amd-gfx mailing list