All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Yiwei Zhang <zzyiwei@google.com>
Cc: Alistair Delva <adelva@google.com>,
	Rohan Garg <rohan.garg@collabora.com>,
	Prahlad Kilambi <prahladk@google.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Kenny Ho <y2kenny@gmail.com>,
	kraxel@redhat.com, Jerome Glisse <jglisse@redhat.com>,
	Sean Paul <seanpaul@chromium.org>,
	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: Wed, 6 Nov 2019 10:56:20 +0100	[thread overview]
Message-ID: <20191106095620.GB23790@phenom.ffwll.local> (raw)
In-Reply-To: <CAKT=dDk1UQmhq6zYa0XCHwJU3utmtoymTa0DPHj195ETJvQfiw@mail.gmail.com>

On Tue, Nov 05, 2019 at 11:45:28AM -0800, Yiwei Zhang wrote:
> Hi Daniel,
> 
> > - The labels are currently free-form, baking them back into your structure
> >  would mean we'd need to do lots of hot add/remove of sysfs directory
> >  trees. Which sounds like a real bad idea :-/
> Given the free form of that ioctl, what's the plan of using that and
> the reporting of the labeled BOs?
> Do you think upstream kernel need to have certain resource category
> based tracking for gpu private allocations?

There's no plan, we simply didn't consider more standardized buckets when
adding that label support. So yeah not sure what to do now, except I don't
want 2 different ways for labelling buffers.

> > - Buffer objects aren't attached to pids, but files. And files can be
> >  shared. If we want to list this somewhere outside of debugfs, we need to
> >  tie this into the files somehow (so proc), except the underlying files
> >  are all anon inodes, so this gets really tricky I think to make work
> >  well.
> So there isn't any gpu private allocations on the upstream side?
> How does upstream deal with duplicate accounting for the shared memory?

Atm we don't account gpu memory anywhere at all. There's a lot of
discussion going on how to remedy that in the context of a cgroup
controller, and how to account allocated buffers against processes is a
huge deal. Maybe cgroups is more the kind of control/reporting you're
looking for? Of course would mean that android creates a cgroup for each
app.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-11-06  9:56 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 [this message]
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
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=20191106095620.GB23790@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --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=rohan.garg@collabora.com \
    --cc=seanpaul@chromium.org \
    --cc=y2kenny@gmail.com \
    --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.