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