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

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

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.

-- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages