On 4/20/21 1:04 PM, Michal Hocko wrote:
On Tue 20-04-21 09:25:51, Peter.Enderborg@sony.com wrote:
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?
No it is better to have a sensible counter that can be reasoned about. So far you are only claiming that having something is better than nothing and I would agree with you if that was a debugging one off interface. But /proc/meminfo and other proc files have to be maintained with future portability in mind. This is not a dumping ground for _some_ counters that might be interesting at the _current_ moment. E.g. what happens if somebody wants to have a per device resp. memory based dma-buf data? Are you going to change the semantic or add another 2 counters?
This is the DmaBufTotal. It is the upper limit. If is not there is is something else.
And when we have a better resolution on measuring it, it would make sense to add a DmaBufVram, DmaBufMemGC or what ever we can pickup.
This is what we can measure today.