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=-0.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 525B1C2D0D3 for ; Mon, 23 Dec 2019 08:11:26 +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 2943920715 for ; Mon, 23 Dec 2019 08:11:26 +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="EymosJpp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2943920715 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 A3B066E1BE; Mon, 23 Dec 2019 08:10:49 +0000 (UTC) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by gabe.freedesktop.org (Postfix) with ESMTPS id 78E286E0D4 for ; Thu, 19 Dec 2019 18:52:39 +0000 (UTC) Received: by mail-lj1-x234.google.com with SMTP id p8so7404897ljg.0 for ; Thu, 19 Dec 2019 10:52:39 -0800 (PST) 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=q3VQ5YSyLgjF9XYAN9lWYlmpq3OBR/OT+NqwafVh5w4=; b=EymosJppu/2ejbFbueHT4tIwHmYgv+zRX5b7o1BP4JFm6pEjKVxrMr6TQ8V9nqIQ5R 1E/VgMrW1d7QpuJOO5iULhdTpbhk63Pe3jIcIpavMah/1Qg9ssxg7ffsxau0gQBUeyK+ 2SWRROAC5kkgPowf8+hOAbfVc49C1cNpzPXQxObiDQbG5YhFp8eBj9S1oGNihuAKqTQP XAK4Fg0hEyaT5i9iLnGnfFQmonMZ7qDCKY48L2NVk0DOYKpIwKKoI5/JiwcpuCSseeBm lEKMijn97iS7a/yZD6qXS4+iopCfJP2Xy1amAnicPN1COLqi4r+bD4fVZZmJxUXo/Gvk lpmA== 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=q3VQ5YSyLgjF9XYAN9lWYlmpq3OBR/OT+NqwafVh5w4=; b=YGL+gOtS+QTqYQlDkedHMRfvrqkDOZaXUUzLbkEgSc4SVJCILSOHle1WBhnTOlX7Ob f1F2dpIilvrOLRC1uYuuIEgxqSpFgWf7l+RbYmZVRKbv9llvQlv1W4LEldfw3IqQa2Pk mx3N5l1mrLP+bsipibjuRLY5cZyDSTdjesrP/ft16hzgeliQPXGRBmMgvLF5tz4ifpJR 4dfYRDEYeVAkU76j5yXgDaRBf7hpltSyR0v2vy8OGp/laEJ/AwPSZPizsxIyDfiulXrR ny6eFFrNJjPdk/ajCN3QKchaYJayQXWvilnYnTOgZuRlezOqMcS7Nmlet6YN5L9nOlZA 8QeA== X-Gm-Message-State: APjAAAVQC8cEE62zBwzt2D9KoocXmQFIrLPa2g8lctKlM7u2C/fASgT3 +TTNgIgZ5r05sV5Kvt998NKU80zNEr1jEKmTYQ1G X-Google-Smtp-Source: APXvYqzuyiZnt51axFHi2e0V1VbNTe9wS43Zp+MtXqT0NLaguhVmr4i/j7X3alA8zp+35nLn9yhxIroSeEKtgyckql0= X-Received: by 2002:a2e:9a01:: with SMTP id o1mr6864229lji.247.1576781557472; Thu, 19 Dec 2019 10:52:37 -0800 (PST) MIME-Version: 1.0 References: <20191112201808.GE31272@redhat.com> <2981882.gi1CFgH74X@saphira> In-Reply-To: <2981882.gi1CFgH74X@saphira> From: Yiwei Zhang Date: Thu, 19 Dec 2019 10:52:26 -0800 Message-ID: Subject: Re: Proposal to report GPU private memory allocations with sysfs nodes [plain text version] To: Rohan Garg X-Mailman-Approved-At: Mon, 23 Dec 2019 08:10:46 +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="===============2107529926==" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --===============2107529926== Content-Type: multipart/alternative; boundary="0000000000009f7560059a13107c" --0000000000009f7560059a13107c Content-Type: text/plain; charset="UTF-8" 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 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//gpu0_meminfo, /proc//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 > > > --0000000000009f7560059a13107c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Rohan,

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 k= now how to find an Intel or Freedreno setup, but I'd still like to know= is there a development=C2=A0friendly Mali setup?

= Many many thanks for all the feedback!
Yiwei

On Thu, Dec 19,= 2019 at 8:18 AM Rohan Garg <rohan.garg@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<= br> > for tracking. Basically I wonder if it's possible for upstream to<= br> > track BOs in a similar way Android tracks dmabuf. Then there's a n= ode
> 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<= br> > 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<= br> > 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 poten= tially
share the same PID.

(2) Specifically in the case of mesa, there isn't a way to (AFAIK) asso= ciate a
BO with a PID.

Cheers
Rohan Garg


--0000000000009f7560059a13107c-- --===============2107529926== 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 --===============2107529926==--