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

[Daniel Vetter]

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