CCed: Paolo Bonzini
On Fri, Oct 16, 2020 at 1:53 PM Minchan Kim [off-list ref] wrote:
[snip]
quoted
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