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

From: Yiwei Zhang <zzyiwei@google.com>
To: Rohan Garg <rohan.garg@collabora.com>
Cc: Alistair Delva <adelva@google.com>,
	Prahlad Kilambi <prahladk@google.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Jerome Glisse <jglisse@redhat.com>, Kenny Ho <y2kenny@gmail.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Sean Paul <seanpaul@chromium.org>,
	Chris Forbes <chrisforbes@google.com>,
	Android Kernel Team <kernel-team@android.com>
Subject: Re: Proposal to report GPU private memory allocations with sysfs nodes [plain text version]
Date: Fri, 20 Mar 2020 14:35:25 -0700	[thread overview]
Message-ID: <CAKT=dD=L8T6vC3N6-ntGmA0qbAULmLv0a81rRS4VSVzC-zL3Kg@mail.gmail.com> (raw)
In-Reply-To: <12494517.uLZWGnKmhe@solembum>

[-- Attachment #1.1: Type: text/plain, Size: 2636 bytes --]

Hi Rohan,

Thanks for your reply! We'd like the standardization to happen in the drm
layer so it can be carried along, however, debugfs has already been
deprecated in Android kernel and tracking per pid is most likely a doable
solution only in the device driver layer. So...since we'd still like the
low-cost run-time query system, we eventually end up doing the
tracepoint[1] + eBPF solution. We standardized a gpu memory total
tracepoint in upstream linux. Then the GPU vendors integrate into their
kernel driver to track those global and per-process total counters. Then we
wrote a bpf c program to track this tracepoint and maintain a map for the
userspace to poke at.

Best regards,
Yiwei

[1] https://lore.kernel.org/lkml/20200302235044.59163-1-zzyiwei@google.com

On Fri, Mar 20, 2020 at 5:07 AM Rohan Garg <rohan.garg@collabora.com> wrote:

> Hi Yiwei
> After some deliberation on how to move forward with my BO Labeling
> patches[1],
> we've come up with the following structure for debugfs entries:
>
> /debugfs/dri/128/bo/<handle>/label
> /debugfs/dri/128/bo/<handle>/size
>
> My initial idea was to count the total memory allocated for a particular
> label
> in kernel space, but that turned out to be far too complicated to
> implement.
> Which is why we decided to move towards something simpler and handle
> collating
> this information on the userspace side of things.
>
> Would this satisfy most of the Android  teams requirements? I understand
> that
> it would leave out the memory tracking requirements tied to a specific
> PID,
> but correct me if I'm wrong, would this not possible with gralloc on
> Android?
>
> Cheers
> Rohan Garg
>
> [1] https://patchwork.freedesktop.org/patch/335508/?series=66752&rev=4
>
> On lunes, 6 de enero de 2020 21:47:21 (CET) Yiwei Zhang wrote:
> > Thanks, I'll check it out.
> >
> > Best,
> > Yiwei
> >
> > On Mon, Jan 6, 2020 at 2:46 AM Rohan Garg <rohan.garg@collabora.com>
> wrote:
> > > Hi Yiwei
> > >
> > > On jueves, 19 de diciembre de 2019 19:52:26 (CET) Yiwei Zhang wrote:
> > > > 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?
> > >
> > > You should be able to setup a Mali T860 compatible device with this
> guide
> > > [1].
> > >
> > > Cheers
> > > Rohan Garg
> > >
> > > [1] https://panfrost.freedesktop.org/building-panfrost-mesa.html
>
>

[-- Attachment #1.2: Type: text/html, Size: 3740 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel