lkml.org 
[lkml]   [2008]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/2] Report the pagesize backing a VMA in /proc/pid/smaps
Date
Hi

> > It is useful to verify a hugepage-aware application is using the expected
> > pagesizes for its memory regions. This patch creates an entry called
> > KernelPageSize in /proc/pid/smaps that is the size of page used by the
> > kernel to back a VMA. The entry is not called PageSize as it is possible
> > the MMU uses a different size. This extension should not break any sensible
> > parser that skips lines containing unrecognised information.
>
> > + "KernelPageSize: %8lu kB\n",
>
> > +unsigned long vma_kernel_pagesize(struct vm_area_struct *vma)
> > +{
> > + struct hstate *hstate;
> > +
> > + if (!is_vm_hugetlb_page(vma))
> > + return PAGE_SIZE;
> > +
> > + hstate = hstate_vma(vma);
> > + VM_BUG_ON(!hstate);
> > +
> > + return 1UL << (hstate->order + PAGE_SHIFT);
> ^^^^
> VM_BUG_ON is unneeded because kernel will oops here if hstate is NULL.

yup.


> Also, in /proc/*/maps it's printed only for hugetlb vmas and called
> hpagesize, in smaps it's printed for every vma and called
> KernelPageSize. All of this is inconsistent.

Is this a problem?
/proc/*/maps and /proc/*/smaps are different purpose file.

/proc/*/maps: summary & suppressed information & easy readable
/proc/*/smaps: verbose output

Already some information output only smaps.


> And app will verify once that hugepages are of right size, so Pss cost
> argument for changing /proc/*/maps seems weak to me.

sorry, I don't understand yet.
Why pss cost changed?





\
 
 \ /
  Last update: 2008-10-09 04:19    [W:0.058 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site