linux-kernel - Re: [PATCH 1/2] Report the pagesize backing a VMA in /proc/pid/smaps

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: <20080924233952.GB8598@csn.ul.ie>
Date:	Thu, 25 Sep 2008 00:39:52 +0100
From:	Mel Gorman <mel@....ul.ie>
To:	Dave Hansen <dave@...ux.vnet.ibm.com>
Cc:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>, agl@...ibm.com,
	LKML <linux-kernel@...r.kernel.org>,
	Linux-MM <linux-mm@...ck.org>
Subject: Re: [PATCH 1/2] Report the pagesize backing a VMA in /proc/pid/smaps

On (24/09/08 12:23), Dave Hansen didst pronounce:
> On Wed, 2008-09-24 at 20:11 +0100, Mel Gorman wrote:
> > I don't get what you mean by it being sprinkled in each smaps file. How
> > would you present the data?
> 
> 1. figure out what the file path is from smaps
> 2. look up the mount
> 3. look up the page sizes from the mount's information
> 

You should be able to do that today but it's not a particularly friendly
task. I expect without decent knowledge of how hugepages work that you'll get
it wrong. A userspace tool could do this of course and likely would use stat
on the file to get teh blocksize if it was hugetlbfs instead of consulting
mounts. It's just not as user-friendly. Consider "cat smaps" as opposed to
download this tool, run it and it'll give you an smaps-like output.

> > > We should be able to figure out which
> > > mount the file is from and, from there, maybe we need some per-mount
> > > information exported.  
> > 
> > Per-mount information is already exported and you can infer the data about
> > huge pagesizes. For example, if you know the default huge pagesize (from
> > /proc/meminfo), and the file is on hugetlbfs (read maps, then /proc/mounts)
> > and there is no pagesize= mount option (mounts again), you could guess what the
> > hugepage that is backing a VMA is. Shared memory segments are a little harder
> > but again, you can infer the information if you look around for long enough.
> > 
> > However, this is awkward and not very user-friendly. With the patches (minus
> > MMUPageSize as I think we've agreed to postpone that), it's easy to see what
> > pagesize is being used at a glance. Without it, you need to know a fair bit
> > about hugepages are implemented in Linux to infer the information correctly.
> 
> I agree completely.  But, if we consider this a user ABI thing, then
> we're stuck with it for a long time, and we better make it flexible
> enough to at least contain the gunk we're planning on adding in a small
> number of years, like the fallback.  We don't want to be adding this
> stuff if it isn't going to be stable.
> 

What's wrong with

KernelPageSize: X kB 

now which a parser can easily handle and later

KernelPageSize: X kb * nX Y kB * nY

where X is a pagesize, nX is the number of pages of that size in a VMA
later? The second format should not break a naive parser.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
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/