On Thu, Aug 27, 2015 at 08:48:18AM +0200, Michal Hocko wrote: > > > 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. > > Yes I am concerned about that and > 9 files changed, 112 insertions(+), 1 deletion(-) > for something that is even not clear to be really required. And I still > haven't heard any strong usecase to justify it. > > 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. That may be a worthwhile tradeoff, I don't know. But at least I realize there is a cost, while you seem to ignore that component. There is value in not painting yourself into a corner. Jörn -- A quarrel is quickly settled when deserted by one party; there is no battle unless there be two. -- Seneca -- 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>