Messages in this thread | | | Date | Wed, 5 Oct 2011 12:19:25 -0700 (PDT) | From | David Rientjes <> | Subject | Re: [RFCv3][PATCH 4/4] show page size in /proc/$pid/numa_maps |
| |
On Wed, 5 Oct 2011, Eric Dumazet wrote:
> > Why on earth do we want to convert a byte value into a string so a script > > can convert it the other way around? Do you have a hard time parsing > > 4096, 2097152, and 1073741824 to be 4K, 2M, and 1G respectively? > > Yes I do. I dont have in my head all possible 2^X values, but K, M, G, > T : thats ok (less neurons needed) > > You focus on current x86_64 hardware. > > Some arches have lot of different choices. (powerpc has 64K, 16M, 16GB > pages) > > In 10 years, you'll have pagesize=549755813888, or maybe > pagesize=8589934592 > > I pretty much prefer pagesize=512GB and pagesize=8TB > > This is consistent with usual conventions and practice. >
I'm indifferent whether it's displayed in bytes (so a script could do pagesize * anon, for example, and find the exact amount of anonymous memory for that vma without needing smaps) or in KB like /proc/pid/smaps, grep Hugepagesize /proc/meminfo, and ls /sys/kernel/mm/hugepages.
In other words, pagesize= in /proc/pid/numa_maps is the least of your worries if you're serious about this: you would have already struggled with smaps, meminfo, and the sysfs interface for reserving the hugepages in the first place.
| |