On 4/20/21 11:12 AM, Michal Hocko wrote:
On Tue 20-04-21 09:02:57, Peter.Enderborg@sony.com 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.