On Thu, Dec 10, 2020 at 11:55 AM Greg KH gregkh@linuxfoundation.org wrote:
On Thu, Dec 10, 2020 at 11:27:27AM +0100, Daniel Vetter wrote:
On Thu, Dec 10, 2020 at 11:10:45AM +0100, Greg KH wrote:
On Thu, Dec 10, 2020 at 10:58:50AM +0100, Christian König wrote:
In general a good idea, but I have a few concern/comments here.
Am 10.12.20 um 05:43 schrieb Hridya Valsaraju:
This patch allows statistics to be enabled for each DMA-BUF in sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS.
The following stats will be exposed by the interface:
/sys/kernel/dmabuf/<inode_number>/exporter_name /sys/kernel/dmabuf/<inode_number>/size /sys/kernel/dmabuf/<inode_number>/dev_map_info
The inode_number is unique for each DMA-BUF and was added earlier [1] in order to allow userspace to track DMA-BUF usage across different processes.
Currently, this information is exposed in /sys/kernel/debug/dma_buf/bufinfo. However, since debugfs is considered unsafe to be mounted in production, it is being duplicated in sysfs.
Mhm, this makes it part of the UAPI. What is the justification for this?
In other words do we really need those debug information in a production environment?
Production environments seem to want to know who is using up memory :)
This only shows shared memory, so it does smell a lot like $specific_issue and we're designing a narrow solution for that and then have to carry it forever.
I think the "issue" is that this was a feature from ion that people "missed" in the dmabuf move. Taking away the ability to see what kind of allocations were being made didn't make a lot of debugging tools happy :(
If this is just for dma-heaps then why don't we add the stuff back over there? It reinforces more that the android gpu stack and the non-android gpu stack on linux are fairly different in fundamental ways, but that's not really new. -Daniel
But Hridya knows more, she's been dealing with the transition for a long time now.
E.g. why is the list of attachments not a sysfs link? That's how we usually expose struct device * pointers in sysfs to userspace, not as a list of things.
These aren't struct devices, so I don't understand the objection here. Where else could these go in sysfs?
Furthermore we don't have the exporter device covered anywhere, how is that tracked? Yes Android just uses ion for all shared buffers, but that's not how all of linux userspace works.
Do we have the exporter device link in the dmabuf interface? If so, great, let's use that, but for some reason I didn't think it was there.
Then I guess there's the mmaps, you can fish them out of procfs. A tool which collects all that information might be useful, just as demonstration of how this is all supposed to be used.
There's a script somewhere that does this today, again, Hridya knows more.
There's also some things to make sure we're at least having thought about how other things fit in here. E.d. dma_resv attached to the dma-buf matters in general a lot. It doesn't matter on Android because everything's pinned all the time anyway.
Also I thought sysfs was one value one file, dumping an entire list into dev_info_map with properties we'll need to extend (once you care about dma_resv you also want to know which attachments are dynamic) does not smell like sysfs design at all.
sysfs is one value per file, what is being exported that is larger than that here? Did I miss something on review?
thanks,
greg k-h _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel