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? -- Michal Hocko SUSE Labs
