On Tue, Sep 22, 2020 at 10:39 AM Chauhan, Madhav <madhav.chau...@amd.com> wrote: > > [AMD Public Use] > > -----Original Message----- > From: Christian König <ckoenig.leichtzumer...@gmail.com> > Sent: Tuesday, September 22, 2020 6:25 PM > To: Chauhan, Madhav <madhav.chau...@amd.com>; Koenig, Christian > <christian.koe...@amd.com>; amd-gfx@lists.freedesktop.org > Cc: Deucher, Alexander <alexander.deuc...@amd.com>; Surampalli, Kishore > <kishore.surampa...@amd.com>; Patel, Mihir <mihir.pa...@amd.com>; Saleem, > Athar <athar.sal...@amd.com>; Sharma, Shashank <shashank.sha...@amd.com> > 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.koe...@amd.com> > > Sent: Tuesday, September 22, 2020 12:15 PM > > To: Chauhan, Madhav <madhav.chau...@amd.com>; > > amd-gfx@lists.freedesktop.org > > Cc: Surampalli, Kishore <kishore.surampa...@amd.com>; Patel, Mihir > > <mihir.pa...@amd.com>; Sharma, Shashank <shashank.sha...@amd.com>; > > Deucher, Alexander <alexander.deuc...@amd.com>; Saleem, Athar > > <athar.sal...@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.leichtzumer...@gmail.com> > >> Sent: Tuesday, September 22, 2020 12:54 AM > >> To: Chauhan, Madhav <madhav.chau...@amd.com>; > >> amd-gfx@lists.freedesktop.org > >> Cc: Surampalli, Kishore <kishore.surampa...@amd.com>; Patel, Mihir > >> <mihir.pa...@amd.com>; Sharma, Shashank <shashank.sha...@amd.com>; > >> Deucher, Alexander <alexander.deuc...@amd.com>; Saleem, Athar > >> <athar.sal...@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. > > 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.chau...@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@lists.freedesktop.org > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > > s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CMa > > dhav.Chauhan%40amd.com%7C13036a57ccd2478eebb108d85ef6b0e8%7C3dd8961fe4 > > 884e608e11a82d994e183d%7C0%7C0%7C637363760926411977&sdata=XORY%2Fh > > iAOLlde1xhc0tUd%2FTQlCyG2cqvVH2Jn%2FiPtF8%3D&reserved=0 > _______________________________________________ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
