Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status
From: David Rientjes
Date: Wed Aug 26 2015 - 18:02:55 EST
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
> 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.