Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status

[David Rientjes]

On Wed, 26 Aug 2015, Michal Hocko wrote:

> I thought the purpose was to give the amount of hugetlb based
> resident memory.

Persistent hugetlb memory is always resident, the goal is to show what is 
currently mapped.

> At least this is what JÃrn was asking for AFAIU.
> /proc/<pid>/status should be as lightweight as possible. The current
> implementation is quite heavy as already pointed out. So I am really
> curious whether this is _really_ needed. I haven't heard about a real
> usecase except for top displaying HRss which doesn't need the break
> down values. You have brought that up already
> http://marc.info/?l=linux-mm&m=143941143109335&w=2 and nobody actually
> asked for it. "I do not mind having it" is not an argument for inclusion
> especially when the implementation is more costly and touches hot paths.
> 

It iterates over HUGE_MAX_HSTATE and reads atomic usage counters twice.  
On x86, HUGE_MAX_HSTATE == 2.  I don't consider that to be expensive.

If you are concerned about the memory allocation of struct hugetlb_usage, 
it could easily be embedded directly in struct mm_struct.