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

Michal Hocko
2015-08-26T06:38:18Z

On Tue 25-08-15 16:23:34, David Rientjes wrote:
> On Mon, 24 Aug 2015, Michal Hocko wrote:
>
> > The current implementation makes me worry. Is the per hstate break down
> > really needed? The implementation would be much more easier without it.
> >
>
> Yes, it's needed. It provides a complete picture of what statically
> reserved hugepages are in use and we're not going to change the
> implementation when it is needed to differentiate between variable hugetlb
> page sizes that risk breaking existing userspace parsers.

I thought the purpose was to give the amount of hugetlb based
resident memory. 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.

> > If you have 99% of hugetlb pages then your load is rather specific and I
> > would argue that /proc/<pid>/smaps (after patch 1) is a much better way to
> > get what you want.
>
> Some distributions change the permissions of smaps, as already stated, for
> pretty clear security reasons since it can be used to defeat existing
> protection. There's no reason why hugetlb page usage should not be
> exported in the same manner and location as memory usage.

/proc/<pid>/status provides only per-memory-type break down information
(locked, data, stack, etc...). Different hugetlb sizes are still a
hugetlb memory. So I am not sure I understand you argument here.
--
Michal Hocko
SUSE Labs