On Fri, Oct 16, 2020 at 05:38:26PM +0200, Vlastimil Babka wrote: > On 10/13/20 10:09 AM, Mike Rapoport wrote: > > > We are not complaining about TCP using too much memory, but how do > > > we know that TCP uses a lot of memory. When I firstly face this problem, > > > I do not know who uses the 25GB memory and it is not shown in the /proc/meminfo. > > > If we can know the amount memory of the socket buffer via /proc/meminfo, we > > > may not need to spend a lot of time troubleshooting this problem. Not everyone > > > knows that a lot of memory may be used here. But I believe many people > > > should know /proc/meminfo to confirm memory users. > > If I undestand correctly, the problem you are trying to solve is to > > simplify troubleshooting of memory usage for people who may not be aware > > that networking stack can be a large memory consumer. > > > > For that a paragraph in 'man 5 proc' maybe a good start: > > Yeah. Another major consumer that I've seen at some point was xfs buffers. As well, there are other various type of memory consumers in embedded world, depending on the features what they supprted, too. They often tempted to add the memory consumption into /proc/meminfo or /proc/vmstat, too to get memory visibility. > 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. Furthermore, I'd like to plug the infra into OOM message so once OOM occurs, we could print each own hidden memory usage from driver side if the driver believe they could be memory hogger. It would make easier to detect such kinds of leak or hogging as well as better maintainace. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
