Re: [RFCv3][PATCH 4/4] show page size in /proc/$pid/numa_maps
From: David Rientjes
Date: Wed Oct 05 2011 - 03:24:10 EST
On Wed, 5 Oct 2011, Eric Dumazet wrote:
> > This would be great if all the /proc/pid/numa_maps consumers were human,
> > but unfortuantely that's not the case.
> > I understand that this patchset was probably the result of me asking for
> > the pagesize= to be specified in each line and using pagesize=4K and
> > pagesize=2M as examples, but that exact usage is probably not what we
> > want.
> > As long as there are scripts that go through and read this information
> > (we have some internally), expressing them with differing units just makes
> > it more difficult to parse. I'd rather them just be the byte count.
> > That way, 1G pages would just show pagesize=1073741824. I don't think
> > that's too long and is much easier to parse systematically.
> Hmm... Thats sounds strange.
> Are you saying you cant change your scripts [But you'll have to anyway
> to parse pagesize=] ?
pagesize= isn't absolutely required, you can already get the thp stats
from /proc/pid/smaps. A script can then parse /proc/pid/numa_maps for the
same vmas to determine the NUMA locality. Adding pagesize= to numa_maps
then doesn't change the script at all if it's robust.
> I routinely use "cat /proc/xxx/numa_maps", and am stuck when a kernel
> displays nothing (it happened on some debian released kernels)
> Seeing pagesize=1GB is slightly better for human, and not that hard to
> parse for a program.
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? Then you
better not use the hugepage sysfs interface to configure multiple hugepage
sizes because they're all specified in kB!
> By the way, "pagesize=4KiB" are just noise if you ask me, thats the
> default PAGE_SIZE. This also breaks old scripts :)
-ENOPARSE. It better not break any old script, I don't know why it would.
Anything that emits a field=value tuple should be parsed as such. I doubt
you can find a well-distributed example since numa_maps output includes
file, mapped, mapmax, anon, and dirty fields and not a single line of
output would have all of them.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/