On Wed 21-04-21 10:37:11, Peter.Enderborg@xxxxxxxx wrote: > On 4/21/21 11:15 AM, Daniel Vetter wrote: [...] > > We need to understand what the "correct" value is. Not in terms of kernel > > code, but in terms of semantics. Like if userspace allocates a GL texture, > > is this supposed to show up in your metric or not. Stuff like that. > That it like that would like to only one pointer type. You need to know what > > you pointing at to know what it is. it might be a hardware or a other pointer. > > If there is a limitation on your pointers it is a good metric to count them > even if you don't know what they are. Same goes for dma-buf, they > are generic, but they consume some resources that are counted in pages. > > It would be very good if there a sub division where you could measure > all possible types separately. We have the detailed in debugfs, but nothing > for the user. A summary in meminfo seems to be the best place for such > metric. I strongly suspect that the main problem of this patch (and its previous versions) is that you are failing to explain the purpose of the counter to others. From what you have said so far it sounds like this is a number which is nice to have because gives us more than nothing. And while this is not really hard to agree with it doesn't really meet the justification for exporting yet another counter to the userspace with all the headache of the future maintenance. I think it would hugely help to describe a typical scenario when the counter would be useful and the conclusion you can draw from the exported value or a set of values over time. And please note that a mixed bag of different memory resources in a single counter doesn't make this any easier because then it essentially makes it impossible to know whether an excessive usage contribues to RAM or device memory depletion - hence this is completely bogus for the OOM report. -- Michal Hocko SUSE Labs
