From: Mel Gorman <mel@csn.ul.ie>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: akpm@linux-foundation.org, kosaki.motohiro@jp.fujitsu.com,
dave@linux.vnet.ibm.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] Report the pagesize backing a VMA in /proc/pid/smaps
Date: Thu, 9 Oct 2008 11:24:36 +0100 [thread overview]
Message-ID: <20081009102436.GD24962@csn.ul.ie> (raw)
In-Reply-To: <20081008213831.GA23729@x200.localdomain>
On (09/10/08 01:38), Alexey Dobriyan didst pronounce:
> On Fri, Oct 03, 2008 at 05:46:54PM +0100, Mel Gorman wrote:
> > 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.
>
Ok, will drop it. I used the VM_BUG_ON so if the situation was triggered,
it would come with line numbers but it'll be an obvious oops so I guess it
is redundant.
> Also, in /proc/*/maps it's printed only for hugetlb vmas and called
> hpagesize,
Well yes... because it's a huge pagesize for that VMA. The name reflects
what is being described there.
> in smaps it's printed for every vma and called
> KernelPageSize. All of this is inconsistent.
>
In smaps, we are printing for every VMA because it's easier for parsers to
deal with the presense of information than its absense. The name KernelPageSize
there is an accurate description.
I don't feel it is inconsistent.
> And app will verify once that hugepages are of right size, so Pss cost
> argument for changing /proc/*/maps seems weak to me.
>
Lets say someone wanted to monitor an application to see what its use of
hugepages were over time, they would have to constantly incur the PSS
cost to do that which seems a bit unfair.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-10-09 10:24 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-03 16:46 [PATCH 0/2] Report the size of pages backing VMAs in /proc V3 Mel Gorman
2008-10-03 16:46 ` [PATCH 1/2] Report the pagesize backing a VMA in /proc/pid/smaps Mel Gorman
2008-10-08 21:38 ` Alexey Dobriyan
2008-10-09 2:16 ` KOSAKI Motohiro
2008-10-09 10:24 ` Mel Gorman [this message]
2008-10-03 16:46 ` [PATCH 2/2] Report the pagesize backing a VMA in /proc/pid/maps Mel Gorman
2008-10-04 8:14 ` KOSAKI Motohiro
2008-10-04 12:04 ` [RFC PATCH] Report the shmid backing a VMA in maps KOSAKI Motohiro
2008-10-04 12:07 ` KOSAKI Motohiro
2008-10-04 21:52 ` Alexey Dobriyan
2008-10-05 5:48 ` KOSAKI Motohiro
2008-10-04 22:13 ` [PATCH 2/2] Report the pagesize backing a VMA in /proc/pid/maps Alexey Dobriyan
2008-10-05 6:00 ` KOSAKI Motohiro
2008-10-06 10:09 ` Mel Gorman
-- strict thread matches above, loose matches on Subject: below --
2008-09-22 1:38 [PATCH 0/2] Report the pagesize backing VMAs in /proc Mel Gorman
2008-09-22 1:38 ` [PATCH 1/2] Report the pagesize backing a VMA in /proc/pid/smaps Mel Gorman
2008-09-22 8:30 ` Andrew Morton
2008-09-22 16:17 ` Mel Gorman
2008-09-22 15:55 ` Dave Hansen
2008-09-22 16:21 ` Mel Gorman
2008-09-22 16:48 ` Dave Hansen
2008-09-23 12:15 ` KOSAKI Motohiro
2008-09-23 19:46 ` Mel Gorman
2008-09-24 12:32 ` KOSAKI Motohiro
2008-09-24 15:41 ` Mel Gorman
2008-09-24 16:06 ` Dave Hansen
2008-09-24 17:10 ` Mel Gorman
2008-09-24 18:59 ` Dave Hansen
2008-09-24 19:11 ` Mel Gorman
2008-09-24 19:23 ` Dave Hansen
2008-09-24 23:39 ` Mel Gorman
2008-09-24 23:42 ` Mel Gorman
2008-09-25 12:23 ` KOSAKI Motohiro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081009102436.GD24962@csn.ul.ie \
--to=mel@csn.ul.ie \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox