linux-kernel - Re: [RFCv3][PATCH 4/4] show page size in /proc/$pid/numa

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1110050012490.18906@chino.kir.corp.google.com>
Date:	Wed, 5 Oct 2011 00:23:59 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
cc:	Dave Hansen <dave@...ux.vnet.ibm.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	James.Bottomley@...senpartnership.com, hpa@...or.com
Subject: Re: [RFCv3][PATCH 4/4] show page size in /proc/$pid/numa_maps

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/