On (24/09/08 12:23), Dave Hansen didst pronounce:
quoted text
> 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.

quoted text
> > > 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/