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.1110051213280.23587@chino.kir.corp.google.com>
Date:	Wed, 5 Oct 2011 12:19:25 -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:

> > 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.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ