CCed: Paolo Bonzini On Fri, Oct 16, 2020 at 1:53 PM Minchan Kim <minchan@xxxxxxxxxx> wrote: [snip] > > And there might be others, and adding everything to /proc/meminfo is not > > feasible. I have once proposed adding a counter called "Unaccounted:" which > > would at least tell the user easily if a significant portion is occupied by > > memory not explained by the other meminfo counters, and look for trends > > (increase = potential memory leak?). For specific prominent consumers not > > covered by meminfo but that have some kind of internal counters, we could > > document where to look, such as /proc/net/sockstat or maybe create some > > /proc/ or /sys directory with file per consumer so that it's still easy to > > check, but without the overhead of global counters and bloated > > /proc/meminfo? > > What have in my mind is to support simple general sysfs infra from MM for > driver/subysstems rather than creating each own memory stat. The API > could support flexible accounting like just global memory consumption and/or > consmption by key(e.g,. pid or each own special) for the detail. > > So, they are all shown under /sys/kernel/mm/misc/ with detail as well as > /proc/meminfo with simple line for global. This reminds me of statsfs [1]. I am wondering if this can be another useful use-case for statsfs. [1] https://lkml.org/lkml/2020/5/26/332
