On 4/20/21 1:04 PM, Michal Hocko wrote: > On Tue 20-04-21 09:25:51, Peter.Enderborg@xxxxxxxx wrote: >> 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? > 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.
