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

[David Rientjes <rientjes@google.com>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1518 bytes --]

On Thu, 27 Aug 2015, JA?rn Engel wrote:

> On Thu, Aug 27, 2015 at 08:48:18AM +0200, Michal Hocko wrote:
> > Can we go with the single and much simpler cumulative number first and
> > only add the break down list if it is _really_ required? We can even
> > document that the future version of /proc/<pid>/status might add an
> > additional information to prepare all the parsers to be more careful.
> 
> I don't care much which way we decide.  But I find your reasoning a bit
> worrying.  If someone asks for a by-size breakup of hugepages in a few
> years, you might have existing binaries that depend on the _absence_ of
> those extra characters on the line.
> 
> Compare:
>   HugetlbPages:      18432 kB
>   HugetlbPages:    1069056 kB (1*1048576kB 10*2048kB)
> 
> Once someone has written a script that greps for 'HugetlbPages:.*kB$',
> you have lost the option of adding anything else to the line.  You have
> created yet another ABI compatibility headache today in order to save
> 112 lines of code.
> 

This is exactly the concern that I have brought up in this thread.  We 
have no other way to sanely export the breakdown in hugepage size without 
new fields being added later with the hstate size being embedded in the 
name itself.

I agree with the code as it stands in -mm today and I'm thankful to Naoya 
that a long-term maintainable API has been established.  Respectfully, I 
have no idea why we are still talking about this and I'm not going to be 
responding further unless something changes in -mm.