lkml.org 
[lkml]   [2011]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.


\
 
 \ /
  Last update: 2011-10-05 21:21    [W:0.061 / U:0.956 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site