On Fri, 7 Aug 2015, Naoya Horiguchi wrote: > Currently smaps reports many zero fields for vma(VM_HUGETLB), which is > inconvenient when we want to know per-task or per-vma base hugetlb usage. > This patch enables these fields by introducing smaps_hugetlb_range(). > > before patch: > > Size: 20480 kB > Rss: 0 kB > Pss: 0 kB > Shared_Clean: 0 kB > Shared_Dirty: 0 kB > Private_Clean: 0 kB > Private_Dirty: 0 kB > Referenced: 0 kB > Anonymous: 0 kB > AnonHugePages: 0 kB > Swap: 0 kB > KernelPageSize: 2048 kB > MMUPageSize: 2048 kB > Locked: 0 kB > VmFlags: rd wr mr mw me de ht > > after patch: > > Size: 20480 kB > Rss: 18432 kB > Pss: 18432 kB > Shared_Clean: 0 kB > Shared_Dirty: 0 kB > Private_Clean: 0 kB > Private_Dirty: 18432 kB > Referenced: 18432 kB > Anonymous: 18432 kB > AnonHugePages: 0 kB > Swap: 0 kB > KernelPageSize: 2048 kB > MMUPageSize: 2048 kB > Locked: 0 kB > VmFlags: rd wr mr mw me de ht > I think this will lead to breakage, unfortunately, specifically for users who are concerned with resource management. An example: we use memcg hierarchies to charge memory for individual jobs, specific users, and system overhead. Memcg is a cgroup, so this is done for an aggregate of processes, and we often have to monitor their memory usage. Each process isn't assigned to its own memcg, and I don't believe common users of memcg assign individual processes to their own memcgs. When a memcg is out of memory, we need to track the memory usage of processes attached to its memcg hierarchy to determine what is unexpected, either as a result of a new rollout or because of a memory leak. To do that, we use the rss exported by smaps that is now changed with this patch. By using smaps rather than /proc/pid/status, we can report where memory usage is unexpected. This would cause our process that manages all memcgs on our systems to break. Perhaps I haven't been as convincing in my previous messages of this, but it's quite an obvious userspace regression. This memory was not included in rss originally because memory in the hugetlb persistent pool is always resident. Unmapping the memory does not free memory. For this reason, hugetlb memory has always been treated as its own type of memory. It would have been arguable back when hugetlbfs was introduced whether it should be included. I'm afraid the ship has sailed on that since a decade has past and it would cause userspace to break if existing metrics are used that already have cleared defined semantics. -- 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>