Messages in this thread | | | Date | Thu, 25 Sep 2008 00:39:52 +0100 | From | Mel Gorman <> | 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
| |