[PATCH] drm/amdgpu: Add uid info to process BO list

[Christian König]

Am 22.09.20 um 12:38 schrieb Chauhan, Madhav:
> [AMD Public Use]
>
> -----Original Message-----
> From: Koenig, Christian <Christian.Koenig at amd.com>
> Sent: Tuesday, September 22, 2020 12:15 PM
> To: Chauhan, Madhav <Madhav.Chauhan at amd.com>; amd-gfx at lists.freedesktop.org
> Cc: Surampalli, Kishore <Kishore.Surampalli at amd.com>; Patel, Mihir <Mihir.Patel at amd.com>; Sharma, Shashank <Shashank.Sharma at amd.com>; Deucher, Alexander <Alexander.Deucher at amd.com>; Saleem, Athar <Athar.Saleem at amd.com>
> Subject: Re: [PATCH] drm/amdgpu: Add uid info to process BO list
>
> Am 21.09.20 um 21:55 schrieb Chauhan, Madhav:
>> [AMD Public Use]
>>
>> -----Original Message-----
>> From: Christian König <ckoenig.leichtzumerken at gmail.com>
>> Sent: Tuesday, September 22, 2020 12:54 AM
>> To: Chauhan, Madhav <Madhav.Chauhan at amd.com>;
>> amd-gfx at lists.freedesktop.org
>> Cc: Surampalli, Kishore <Kishore.Surampalli at amd.com>; Patel, Mihir
>> <Mihir.Patel at amd.com>; Sharma, Shashank <Shashank.Sharma at amd.com>;
>> Deucher, Alexander <Alexander.Deucher at amd.com>; Saleem, Athar
>> <Athar.Saleem at amd.com>
>> Subject: Re: [PATCH] drm/amdgpu: Add uid info to process BO list
>>
>> Am 21.09.20 um 21:18 schrieb Madhav Chauhan:
>>> UID is helpful while doing analysis of BO allocated by a process.
>> Looks like a bit overkill to me, why not get the uid from the process info?
>>
>> Not sure if I got your point , but used the similar method implemented
>> at drm level inside drm_debugfs.c. Thanks
> Good argument, but I'm not sure if we should duplicate that here. What do you need this for?
>
> Thanks, We need details of BOs allocated by a process and associated UID so that we can do memory perf analysis using some scripts
> To find the top consumer of GPU memory and see if those application can be optimized.
>
> Clients information at DRM level doesn’t print list of BO per process and since that is handled by amdgpu driver specific
> Functions.  So all the BO list information at one place is really useful and needed by our customers as various other vendors
> Already provide this.

Well that is exactly the explanation I didn't want to hear :(

See both the drm client list as well as the amdgpu GEM info are only 
debugfs files and only intended for providing some information for 
debugging and are not 100% reliable for the use case you have here.

The first problem is that on modern installations the file descriptor is 
often opened by the X server instead of the application.

So for example you end up with:
> pid     1382 command Xorg:
>     0x00000001:      2097152 byte VRAM @ 0x0000002a00
>     0x00000002:         4096 byte  GTT @ 0x00000006c7
> ....
>     0x00000090:       266240 byte VRAM @ 0x000005e800
>     0x00000091:      2097152 byte VRAM @ 0x000004e200
>     0x00000092:      2097152 byte  GTT
> pid     1382 command Xorg:
>     0x00000001:      2097152 byte VRAM @ 0x0000002800
> ...

Then next problem is that the amdgpu_gem_info is completely inaccurate 
regarding the used memory of an application, since the same BO is 
sometimes opened multiple times. That's also the reason why we don't 
provide a total of the consumed memory. It basically just informs you 
which handle is what.

Then last the debugfs files are not a stable interface and not meant to 
be consumed by scripts and/or frontend applications. You should instead 
use sysfs for this.

Regards,
Christian.

>
> Regards,
> Madhav
>
> Christian.
>
>> Regards,
>> Madhav
>>
>> Christian.
>>
>>> Signed-off-by: Madhav Chauhan <madhav.chauhan at amd.com>
>>> ---
>>>     drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 +++++-
>>>     1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> index f4c2e2e75b8f..c1982349ec7b 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> @@ -892,6 +892,7 @@ static int amdgpu_debugfs_gem_info(struct seq_file *m, void *data)
>>>     	struct drm_info_node *node = (struct drm_info_node *)m->private;
>>>     	struct drm_device *dev = node->minor->dev;
>>>     	struct drm_file *file;
>>> +	kuid_t uid;
>>>     	int r;
>>>     
>>>     	r = mutex_lock_interruptible(&dev->filelist_mutex);
>>> @@ -909,7 +910,10 @@ static int amdgpu_debugfs_gem_info(struct seq_file *m, void *data)
>>>     		 */
>>>     		rcu_read_lock();
>>>     		task = pid_task(file->pid, PIDTYPE_PID);
>>> -		seq_printf(m, "pid %8d command %s:\n", pid_nr(file->pid),
>>> +		uid = task ? __task_cred(task)->euid : GLOBAL_ROOT_UID;
>>> +		seq_printf(m, "pid %8d uid %5d command %s:\n",
>>> +			   pid_nr(file->pid),
>>> +			   from_kuid_munged(seq_user_ns(m), uid),
>>>     			   task ? task->comm : "<unknown>");
>>>     		rcu_read_unlock();
>>>     
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx