Proposal to report GPU private memory allocations with sysfs nodes [plain text version]

[Yiwei Zhang]

Hi Rohan,

Thanks for pointing out the pids issue! Then the index would be {namespace
+ pid(in that namespace)}. I'll grab a setup and play with the driver to
see what I can do. I know how to find an Intel or Freedreno setup, but I'd
still like to know is there a development friendly Mali setup?

Many many thanks for all the feedback!
Yiwei

On Thu, Dec 19, 2019 at 8:18 AM Rohan Garg <rohan.garg at collabora.com> wrote:

> Hey
>
> > Is it reasonable to add another ioctl or something equivalent to label
> > a BO with what PID makes the allocation? When the BO gets shared to
> > other processes, this information also needs to be bookkept somewhere
> > for tracking. Basically I wonder if it's possible for upstream to
> > track BOs in a similar way Android tracks dmabuf. Then there's a node
> > implemented by cgroup in proc listing all the BOs per process with
> > information like label, refcount, etc. Then Android GPU vendors can
> > implement the same nodes which is going to be compatible even if they
> > later adopts drm subsystem.
> >
> > So my sketch idea for the nodes are:
> > (1) /proc/gpu0_meminfo, /proc/gpu1_meminfo
> > This is a list of all BOs with pids holding a reference to it and the
> > current label of each BO
> > (2) /proc/<pid>/gpu0_meminfo, /proc/<pid>/gpu1_meminfo
> > This is a list of all BOs this process holds a reference to.
> > (3) Is it reasonable to implement another nodes for {total,
> > total_unmapped} counters? or just surface through /proc/meminfo?
> >
>
> This would be tricky to implement because:
>
> (1) PID's are not unique, PID namespaces allow linux userspace to
> potentially
> share the same PID.
>
> (2) Specifically in the case of mesa, there isn't a way to (AFAIK)
> associate a
> BO with a PID.
>
> Cheers
> Rohan Garg
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20191219/b18c8b1c/attachment-0001.htm>