<div dir="ltr"><div dir="ltr"><span style="">On Tue, 20 Apr 2021 at 14:46, <<a href="mailto:Peter.Enderborg@sony.com">Peter.Enderborg@sony.com</a>> wrote:</span><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/20/21 3:34 PM, Daniel Stone wrote:<br>> On Fri, 16 Apr 2021 at 13:34, Peter Enderborg <<a href="mailto:peter.enderborg@sony.com" target="_blank">peter.enderborg@sony.com</a> <mailto:<a href="mailto:peter.enderborg@sony.com" target="_blank">peter.enderborg@sony.com</a>>> wrote:<br>>     This adds a total used dma-buf memory. Details<br>
>     can be found in debugfs, however it is not for everyone<br>
>     and not always available. dma-buf are indirect allocated by<br>
>     userspace. So with this value we can monitor and detect<br>
>     userspace applications that have problems.<br>
><br>
><br>
> FWIW, this won't work super well for Android where gralloc is implemented as a system service, so all graphics usage will instantly be accounted to it.<br><br>
This resource allocation is a big part of why we need it. Why should it not work?<br></blockquote><div><br></div><div>Sorry, I'd somehow completely misread that as being locally rather than globally accounted. Given that, it's more correct, just also not super useful.</div><div><span style=""><br></span></div><div><span style="">Some drivers export allocation tracepoints which you could use if you have a decent userspace tracing infrastructure. Short of that, many drivers export this kind of thing through debugfs already. I think a better long-term direction is probably getting accounting from dma-heaps rather than extending core dmabuf itself.</span></div><div><span style=""><br></span></div><div><span style="">Cheers,</span></div><div><span style="">Daniel </span></div></div></div>