On 4/20/21 11:12 AM, Michal Hocko wrote: > On Tue 20-04-21 09:02:57, Peter.Enderborg@xxxxxxxx wrote: >>>> But that isn't really system memory at all, it's just allocated device >>>> memory. >>> OK, that was not really clear to me. So this is not really accounted to >>> MemTotal? If that is really the case then reporting it into the oom >>> report is completely pointless and I am not even sure /proc/meminfo is >>> the right interface either. It would just add more confusion I am >>> afraid. >>> >> Why is it confusing? Documentation is quite clear: > Because a single counter without a wider context cannot be put into any > reasonable context. There is no notion of the total amount of device > memory usable for dma-buf. As Christian explained some of it can be RAM > based. So a single number is rather pointless on its own in many cases. > > Or let me just ask. What can you tell from dma-bud: $FOO kB in its > current form? It is better to be blind? The value can still be used a relative metric. You collect the data and see how it change. And when you see a unexpected change you start to dig in. It fore sure wont tell what line in your application that has a bug. But it might be an indicator that a new game trigger a leak. And it is very well specified, it exactly the size of mapped dma-buf. For what you use dma-buf you need to know other parts of the system. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
