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@xxxxxxxxxxxxx> 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
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
