Messages in this thread | | | From | KOSAKI Motohiro <> | Subject | Re: [PATCH 1/2] Report the pagesize backing a VMA in /proc/pid/smaps | Date | Thu, 9 Oct 2008 11:16:58 +0900 (JST) |
| |
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?
| |