[lkml]   [2008]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/2] Report the pagesize backing a VMA in /proc/pid/smaps
    On (24/09/08 11:59), Dave Hansen didst pronounce:
    > On Wed, 2008-09-24 at 18:10 +0100, Mel Gorman wrote:
    > > On (24/09/08 09:06), Dave Hansen didst pronounce:
    > > > On Wed, 2008-09-24 at 16:41 +0100, Mel Gorman wrote:
    > > > > I admit it's ppc64-specific. In the latest patch series, I made this a
    > > > > separate patch so that it could be readily dropped again for this reason.
    > > > > Maybe an alternative would be to display MMUPageSize *only* where it differs
    > > > > from KernelPageSize. Would that be better or similarly confusing?
    > > >
    > > > I would also think that any arch implementing fallback from large to
    > > > small pages in a hugetlbfs area (Adam needs to post his patches :) would
    > > > also use this.
    > > >
    > >
    > > Fair point. Maybe the thing to do is backburner this patch for the moment and
    > > reintroduce it when/if an architecture supports demotion? The KernelPageSize
    > > reporting in smaps and what the hpagesize in maps is still useful though
    > > I believe. Any comment?
    > I'd kinda prefer to see it normalized into a single place rather than
    > sprinkle it in each smaps file.

    I don't get what you mean by it being sprinkled in each smaps file. How
    would you present the data?

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

    > > (future stuff from here on)
    > >
    > > In the future if demotion does happen then the MMUPageSize information may
    > > be genuinely useful instead of just a curious oddity on ppc64. As you point
    > > out, Adam (added to cc) has worked on this area (starting with x86 demotion)
    > > in the past but it's a while before it'll be considered for merging I believe.
    > >
    > > That aside, more would need to be done with the page size reporting then
    > > anyway. For example, it maybe indicate how much of each pagesize is in a VMA
    > > or indicate that KernelPageSize is what is being requested but in reality
    > > it is mixed like;
    > >
    > > KernelPageSize: 2048 kB (mixed)
    > >
    > > or
    > >
    > > KernelPageSize: 2048 kB * 5, 4096 kB * 20
    > Looks a bit verbose, but I agree with the sentiment.

    Grand, I'll keep note of this to revisit it in the future when/if
    pagesizes get mixed in a VMA. Thanks

    Mel Gorman
    Part-time Phd Student Linux Technology Center
    University of Limerick IBM Dublin Software Lab

     \ /
      Last update: 2008-09-24 21:13    [W:0.029 / U:7.228 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site