From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: ** X-Spam-Status: No, score=2.5 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29F3BC4332E for ; Sat, 21 Mar 2020 10:45:04 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F0EC2206F9 for ; Sat, 21 Mar 2020 10:45:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="umvvKuUp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F0EC2206F9 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B41846E312; Sat, 21 Mar 2020 10:44:57 +0000 (UTC) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7BE0C6EB6D for ; Fri, 20 Mar 2020 21:35:39 +0000 (UTC) Received: by mail-lf1-x144.google.com with SMTP id t21so5705333lfe.9 for ; Fri, 20 Mar 2020 14:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OCDsP/U4Ms1AhLHpI7SZoQLxQGHhjcNRvpYOI8469D8=; b=umvvKuUp0qCw0SMhrr9YFFX35Pb2FD3pqboXfGroPGL0ICbyN1BL7SZXZFp02pzaWh V6kcLZhvWlcSBhhPi0qxn1Gm3lHSw7/xV1fsPRwfhPfoMxivbqqXKQuL8YDEM2tI3Fz7 2LYuvxK/wv522r8zC/uM1rvq96H8vvsreGNxpjDAtRfnpTCG6lhSnKJAF2Ipn4Epvz20 UhCqFfkMUjXMrR72JvKuhxhz5Bwb/EV2cnpcARjBLhiNIQIHedi9GDbgA3gNwk71YLyV j2F/YJRipjLIEkMV990PRiUIF4lLERdU4a7XBZHRqtSvo1oNMLIu8c2YvuZxu7oOLLcd 4gLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OCDsP/U4Ms1AhLHpI7SZoQLxQGHhjcNRvpYOI8469D8=; b=E7vrSii9zMgXMEIhftLh8SzmKZ5ryPlD8uGSzCg+wQDXF5jb9lQxyfj3c3+F4ceCvX xKEYhNzm0uXniQZFUtcDsWs9ovT9JDrK9YHRaC5vlyR3XyLBZjbvN6lncZJEAceks9dW U4rMfTdarynFO+BipGPUruSIaZEi3eGaI/YSnQxDXDxv7uChOzH8EXOh7qudNfZUcBrt nt4NMjDfKHZVodahn2fiZ+245LqU1QsRj6/1o1YLZVk8lHO5BlQ/vztdEtNXa06fauxK F99rvcvNV+xtpWv/q7UXmG4VuZydg5Ebpz8gK4qmdHqfI3rid5guN47AAKWz/0VFszfx Cqog== X-Gm-Message-State: ANhLgQ14PtqeANUoGEtVLxZaRVzmFrw3FMaQVFmBxn+yk6z8w61NpEpO nMnkmFTdaENiAxWv1LMmIhwugPoVJAngwjrqq9xb X-Google-Smtp-Source: ADFU+vvhJxTDjPKM0Tsq1MZWycwDxA87bamtVlGnPU4b7YpTwEb/JWmpXMOT57yZxKG1ocPE4lHlHg3iBmmLX09BNR4= X-Received: by 2002:a05:6512:1054:: with SMTP id c20mr6439799lfb.69.1584740136982; Fri, 20 Mar 2020 14:35:36 -0700 (PDT) MIME-Version: 1.0 References: <1931035.d46ecxlGCF@saphira> <12494517.uLZWGnKmhe@solembum> In-Reply-To: <12494517.uLZWGnKmhe@solembum> From: Yiwei Zhang Date: Fri, 20 Mar 2020 14:35:25 -0700 Message-ID: Subject: Re: Proposal to report GPU private memory allocations with sysfs nodes [plain text version] To: Rohan Garg X-Mailman-Approved-At: Sat, 21 Mar 2020 10:44:31 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alistair Delva , Prahlad Kilambi , dri-devel , Jerome Glisse , Kenny Ho , Gerd Hoffmann , Sean Paul , Chris Forbes , Android Kernel Team Content-Type: multipart/mixed; boundary="===============0461172036==" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --===============0461172036== Content-Type: multipart/alternative; boundary="000000000000ed872905a15010d6" --000000000000ed872905a15010d6 Content-Type: text/plain; charset="UTF-8" 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 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//label > /debugfs/dri/128/bo//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 > 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 > > --000000000000ed872905a15010d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rohan,

Thanks for your reply! We'd like the = standardization to happen in the drm layer so it can be carried along, howe= ver, 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 eventuall= y end up doing the tracepoint[1] + eBPF solution. We standardized a gpu mem= ory 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 f= or the userspace to poke at.

Best regards,


On Fri, Mar 20, 2020 at 5= :07 AM Rohan Garg <rohan.gar= g@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 la= bel
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 collat= ing
this information on the userspace side of things.

Would this satisfy most of the Android=C2=A0 teams requirements? I understa= nd 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 An= droid?

Cheers
Rohan Garg

[1] https://patchwork.free= desktop.org/patch/335508/?series=3D66752&rev=3D4

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> wrot= e:
> > Hi Yiwei
> >
> > On jueves, 19 de diciembre de 2019 19:52:26 (CET) Yiwei Zhang wro= te:
> > > 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 wi= th 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 setu= p?
> >
> > You should be able to setup a Mali T860 compatible device with th= is guide
> > [1].
> >
> > Cheers
> > Rohan Garg
> >
> > [1] https://panfrost.freedeskt= op.org/building-panfrost-mesa.html

--000000000000ed872905a15010d6-- --===============0461172036== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0461172036==--