@codonell I'm confused as to why the anon vma name would be useful for determining the VMA's owner? And under what circumstances are you unaware of the mm that owns it (i.e. vma->vm_mm)?

Even from proc's perspective you're pulling it from /proc/$pid/maps at which point you're aware of who it belongs to?

I may be missing something here!

@ljs The ownership model that matters to me is finding the code that called mmap() and determining the reason. For example: glibc allocated arena heaps, which we now decorate (https://inbox.sourceware.org/libc-alpha/[email protected]/T/) When assembling an application with hundreds of shared objects it isn't obvious over time who owns which anonymous mappings.

@ljs The alternative solution to decoration is instrumentation. You run something, like systemtap, bpftrace, etc. to trace ALL mmap syscalls and record the stack callchain to identify the caller and possible cause. This is quite noisy because it contains transiently created mappings that may not really matter to total RSS usage. The even better alternative is extending massif or heaptrack to do this kind of instrumentation.