On Wed, Jul 3, 2013 at 9:54 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Colin Cross <ccross@xxxxxxxxxxx> writes: > >> Userspace processes often have multiple allocators that each do >> anonymous mmaps to get memory. When examining memory usage of >> individual processes or systems as a whole, it is useful to be >> able to break down the various heaps that were allocated by >> each layer and examine their size, RSS, and physical memory >> usage. > > What is the advantage of this? It looks like it is going to add cache > line contention (atomic_inc/atomic_dec) to every vma operation > especially in the envision use case of heavy vma_name sharing. > > I would expect this will result in a bloated vm_area_struct and a slower > mm subsystem. The advantage is better tracking of the impact of various userspace allocations on the overall system. Userspace could track allocations on its own, but it cannot track things like physical memory usage or Kernel SamePage Merging per allocation. The disadvantage is one pointer per vma struct, which would increase the size on an allnoconfig x86_64 kernel from 176 to 184, which puts the vm_name pointer in the same cache line as vm_file. For non-named vmas there is no other cost. For named vmas there will be some cacheline contention, but no more than caused by the vm_file refcount. The refcounting happens at the same time as the vm_file refcounting, and I expect most uses of vm_name to be on anonymous memory, so in general it will make the cost of named anonymous mappings the same as file mappings. > Have you done any benchmarks that stress the mm subsystem? Not yet, but it's on my list. > How can adding glittler to /proc/<pid>/maps and /proc/<pid>/smaps > justify putting a hand break on the linux kernel? I expect "hand break" is overstating the impact. I could put it behind a CONFIG_DEBUG_NAMED_VMAS option, but that seems unnecessary since the impact for systems that choose not to use MADV_NAME will be tiny. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>