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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
