All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Yiwei Zhang <zzyiwei@google.com>
Cc: Alistair Delva <adelva@google.com>,
	Prahlad Kilambi <prahladk@google.com>,
	dri-devel@lists.freedesktop.org,
	Jerome Glisse <jglisse@redhat.com>,
	Sean Paul <seanpaul@chromium.org>,
	kraxel@redhat.com, Chris Forbes <chrisforbes@google.com>,
	kernel-team@android.com
Subject: Re: Proposal to report GPU private memory allocations with sysfs nodes [plain text version]
Date: Tue, 29 Oct 2019 10:33:04 +0200	[thread overview]
Message-ID: <20191029103304.29142c34@eldfell.localdomain> (raw)
In-Reply-To: <CAKT=dDnXwa76_aOVhTaKyE2=2HT2qGHvP9HGqnMzArr-Jt3A+Q@mail.gmail.com>


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

On Mon, 28 Oct 2019 11:33:57 -0700
Yiwei Zhang <zzyiwei@google.com> wrote:

> On Mon, Oct 28, 2019 at 8:26 AM Jerome Glisse <jglisse@redhat.com> wrote:
> 
> > On Fri, Oct 25, 2019 at 11:35:32AM -0700, Yiwei Zhang wrote:  
> > > Hi folks,
> > >
> > > This is the plain text version of the previous email in case that was
> > > considered as spam.

Hi,

you still had a HTML attachment. More comments below.

> > >
> > > --- Background ---
> > > On the downstream Android, vendors used to report GPU private memory
> > > allocations with debugfs nodes in their own formats. However, debugfs  
> > nodes  
> > > are getting deprecated in the next Android release.  

...

> > For the 2nd level "pid", there are usually just a couple of them per  
> > > snapshot, since we only takes snapshot for the active ones.  
> >
> > ? Do not understand here, you can have any number of applications with
> > GPU objects ? And thus there is no bound on the number of PID. Please
> > consider desktop too, i do not know what kind of limitation android
> > impose.
> >  
> 
> We are only interested in tracking *active* GPU private allocations. So
> yes, any
> application currently holding an active GPU context will probably has a
> node here.
> Since we want to do profiling for specific apps, the data has to be per
> application
> based. I don't get your concerns here. If it's about the tracking overhead,
> it's rare
> to see tons of application doing private gpu allocations at the same time.
> Could
> you help elaborate a bit?

Toolkits for the Linux desktop, at least GTK 4, are moving to
GPU-accelerated rendering by default AFAIK. This means that every
application using such toolkit will have an active GPU context created
and used at all times. So potentially every single end user application
running in a system may have a GPU context, even a simple text editor.

In my opinion tracking per process is good, but you cannot sidestep the
question of tracking performance by saying that there is only few
processes using the GPU.

What is an "active" GPU private allocation? This implies that there are
also inactive allocations, what are those?


Let's say you have a bunch of apps and the memory consumption is spread
out into sysfs files like you propose. How would one get a coherent
view of total GPU private memory usage in a system? Iterating through
all sysfs files in userspace and summing up won't work, because each
file will be sampled at a different time, which means the result is not
coherent. Separate files for accumulated statistics perhaps?

What about getting a coherent view of the total GPU private memory
consumption of a single process? I think the same caveat and solution
would apply.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

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

  parent reply	other threads:[~2019-10-29  8:33 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-25 18:35 Proposal to report GPU private memory allocations with sysfs nodes [plain text version] Yiwei Zhang
2019-10-28 15:26 ` Jerome Glisse
2019-10-28 18:33   ` Yiwei Zhang
2019-10-29  1:19     ` Yiwei Zhang
2019-10-31  5:23       ` Kenny Ho
2019-10-31 16:59         ` Yiwei Zhang
2019-10-31 17:57           ` Kenny Ho
2019-11-01  8:36             ` Pekka Paalanen
2019-11-04 19:34               ` Yiwei Zhang
2019-11-05  9:47                 ` Daniel Vetter
2019-11-05 19:45                   ` Yiwei Zhang
2019-11-06  9:56                     ` Daniel Vetter
2019-11-06 16:55                   ` Rob Clark
2019-11-06 19:21                     ` Yiwei Zhang
2019-11-12 18:17                       ` Yiwei Zhang
2019-11-12 20:18                         ` Jerome Glisse
2019-11-15  1:02                           ` Yiwei Zhang
2019-12-13 22:09                             ` Yiwei Zhang
2019-12-19 16:18                             ` Rohan Garg
2019-12-19 18:52                               ` Yiwei Zhang
2020-01-06 10:46                                 ` Rohan Garg
2020-01-06 20:47                                   ` Yiwei Zhang
2020-03-20 12:07                                     ` Rohan Garg
2020-03-20 21:35                                       ` Yiwei Zhang
2019-10-29  8:33     ` Pekka Paalanen [this message]
2019-10-30 21:03       ` Yiwei Zhang
2019-10-30 22:06         ` Yiwei Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191029103304.29142c34@eldfell.localdomain \
    --to=ppaalanen@gmail.com \
    --cc=adelva@google.com \
    --cc=chrisforbes@google.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jglisse@redhat.com \
    --cc=kernel-team@android.com \
    --cc=kraxel@redhat.com \
    --cc=prahladk@google.com \
    --cc=seanpaul@chromium.org \
    --cc=zzyiwei@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.