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

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

 



On Tue, Sep 22, 2020 at 10:39 AM Chauhan, Madhav <Madhav.Chauhan@xxxxxxx> wrote:
>
> [AMD Public Use]
>
> -----Original Message-----
> From: Christian König <ckoenig.leichtzumerken@xxxxxxxxx>
> Sent: Tuesday, September 22, 2020 6:25 PM
> To: Chauhan, Madhav <Madhav.Chauhan@xxxxxxx>; Koenig, Christian <Christian.Koenig@xxxxxxx>; amd-gfx@xxxxxxxxxxxxxxxxxxxxx
> Cc: Deucher, Alexander <Alexander.Deucher@xxxxxxx>; Surampalli, Kishore <Kishore.Surampalli@xxxxxxx>; Patel, Mihir <Mihir.Patel@xxxxxxx>; Saleem, Athar <Athar.Saleem@xxxxxxx>; Sharma, Shashank <Shashank.Sharma@xxxxxxx>
> Subject: Re: [PATCH] drm/amdgpu: Add uid info to process BO list
>
> Am 22.09.20 um 12:38 schrieb Chauhan, Madhav:
> > [AMD Public Use]
> >
> > -----Original Message-----
> > From: Koenig, Christian <Christian.Koenig@xxxxxxx>
> > Sent: Tuesday, September 22, 2020 12:15 PM
> > To: Chauhan, Madhav <Madhav.Chauhan@xxxxxxx>;
> > amd-gfx@xxxxxxxxxxxxxxxxxxxxx
> > Cc: Surampalli, Kishore <Kishore.Surampalli@xxxxxxx>; Patel, Mihir
> > <Mihir.Patel@xxxxxxx>; Sharma, Shashank <Shashank.Sharma@xxxxxxx>;
> > Deucher, Alexander <Alexander.Deucher@xxxxxxx>; Saleem, Athar
> > <Athar.Saleem@xxxxxxx>
> > 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@xxxxxxxxx>
> >> Sent: Tuesday, September 22, 2020 12:54 AM
> >> To: Chauhan, Madhav <Madhav.Chauhan@xxxxxxx>;
> >> amd-gfx@xxxxxxxxxxxxxxxxxxxxx
> >> Cc: Surampalli, Kishore <Kishore.Surampalli@xxxxxxx>; Patel, Mihir
> >> <Mihir.Patel@xxxxxxx>; Sharma, Shashank <Shashank.Sharma@xxxxxxx>;
> >> Deucher, Alexander <Alexander.Deucher@xxxxxxx>; Saleem, Athar
> >> <Athar.Saleem@xxxxxxx>
> >> 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.
>
> Thanks for clarifying.
> UID should remain consistent even though X Server opens device on behalf of App??
> Do you mean we may have entry for same BO inside file1->object_idr and file2->object_idr ??
>
> So which interface inside sysfs/ we need to use to get:
> - Total Memory consumed by an application/pid
> - Details of BO like size, domain  (VRAM/GTT) etc per application/pid??

Whether you use this interface or another, it's not clear how you
should do the accounting for shared buffers.

Alex

>
> Regards,
> Madhav
>
> Regards,
> Christian.
>
> >
> > Regards,
> > Madhav
> >
> > Christian.
> >
> >> Regards,
> >> Madhav
> >>
> >> Christian.
> >>
> >>> Signed-off-by: Madhav Chauhan <madhav.chauhan@xxxxxxx>
> >>> ---
> >>>     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@xxxxxxxxxxxxxxxxxxxxx
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&amp;data=02%7C01%7CMa
> > dhav.Chauhan%40amd.com%7C13036a57ccd2478eebb108d85ef6b0e8%7C3dd8961fe4
> > 884e608e11a82d994e183d%7C0%7C0%7C637363760926411977&amp;sdata=XORY%2Fh
> > iAOLlde1xhc0tUd%2FTQlCyG2cqvVH2Jn%2FiPtF8%3D&amp;reserved=0
> _______________________________________________
> 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