On Wed, Apr 21, 2021 at 10:37:11AM +0000, Peter.Enderborg@xxxxxxxx wrote: > On 4/21/21 11:15 AM, Daniel Vetter wrote: > > > > We need to understand what the "correct" value is. Not in terms of kernel > > code, but in terms of semantics. Like if userspace allocates a GL texture, > > is this supposed to show up in your metric or not. Stuff like that. > That it like that would like to only one pointer type. You need to know what > > you pointing at to know what it is. it might be a hardware or a other pointer. > > If there is a limitation on your pointers it is a good metric to count them > even if you don't know what they are. Same goes for dma-buf, they > are generic, but they consume some resources that are counted in pages. > > It would be very good if there a sub division where you could measure > all possible types separately. We have the detailed in debugfs, but nothing > for the user. A summary in meminfo seems to be the best place for such > metric. Let me try to summarize my understanding of the problem, maybe it'll help others as well. A device driver allocates memory and exports this memory via dma-buf so that this memory will be accessible for userspace via a file descriptor. The allocated memory can be either allocated with alloc_page() from system RAM or by other means from dedicated VRAM (that is not managed by Linux mm) or even from on-device memory. The dma-buf driver tracks the amount of the memory it was requested to export and the size it sees is available at debugfs and fdinfo. The debugfs is not available to user and maybe entirely disabled in production systems. There could be quite a few open dma-bufs so there is no overall summary, plus fdinfo in production systems your refer to is also unavailable to the user because of selinux policy. And there are a few details that are not clear to me: * Since DRM device drivers seem to be the major user of dma-buf exports, why cannot we add information about their memory consumption to, say, /sys/class/graphics/drm/cardX/memory-usage? * How exactly user generates reports that would include the new counters? From my (mostly outdated) experience Android users won't open a terminal and type 'cat /proc/meminfo' there. I'd presume there is a vendor agent that collects the data and sends it for analysis. In this case what is the reason the vendor is unable to adjust selinix policy so that the agent will be able to access fdinfo? * And, as others already mentioned, it is not clear what are the problems that can be detected by examining DmaBufTotal except saying "oh, there is too much/too little memory exported via dma-buf". What would be user visible effects of these problems? What are the next steps to investigate them? What other data will be probably required to identify root cause? -- Sincerely yours, Mike.
