From: Andrew Morton <akpm@osdl.org>
To: David Singleton <dsingleton@mvista.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: new procfs memory analysis feature
Date: Thu, 7 Dec 2006 14:36:11 -0800 [thread overview]
Message-ID: <20061207143611.7a2925e2.akpm@osdl.org> (raw)
In-Reply-To: <45789124.1070207@mvista.com>
On Thu, 07 Dec 2006 14:09:40 -0800
David Singleton <dsingleton@mvista.com> wrote:
>
> Andrew,
>
> this implements a feature for memory analysis tools to go along with
> smaps.
> It shows reference counts for individual pages instead of aggregate
> totals for a given VMA.
> It helps memory analysis tools determine how well pages are being
> shared, or not,
> in a shared libraries, etc.
>
> The per page information is presented in /proc/<pid>/pagemaps.
>
I think the concept is not a bad one, frankly - this requirement arises
frequently. What bugs me is that it only displays the mapcount and
dirtiness. Perhaps there are other things which people want to know. I'm
not sure what they would be though.
I wonder if it would be insane to display the info via a filesystem:
cat /mnt/pagemaps/$(pidof crond)/pgd0/pmd1/pte45
Probably it would.
> Index: linux-2.6.18/Documentation/filesystems/proc.txt
Against 2.6.18? I didn't know you could still buy copies of that ;)
This patch's changelog should include sample output.
Your email client wordwraps patches, and it replaces tabs with spaces.
> ...
>
> +static void pagemaps_pte_range(struct vm_area_struct *vma, pmd_t *pmd,
> + unsigned long addr, unsigned long end,
> + struct seq_file *m)
> +{
> + pte_t *pte, ptent;
> + spinlock_t *ptl;
> + struct page *page;
> + int mapcount = 0;
> +
> + pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
> + do {
> + ptent = *pte;
> + if (pte_present(ptent)) {
> + page = vm_normal_page(vma, addr, ptent);
> + if (page) {
> + if (pte_dirty(ptent))
> + mapcount = -page_mapcount(page);
> + else
> + mapcount = page_mapcount(page);
> + } else {
> + mapcount = 1;
> + }
> + }
> + seq_printf(m, " %d", mapcount);
> +
> + } while (pte++, addr += PAGE_SIZE, addr != end);
Well that's cute. As long as both seq_file and pte-pages are of size
PAGE_SIZE, and as long as pte's are more than three bytes, this will not
overflow the seq_file output buffer.
hm. Unless the pages are all dirty and the mapcounts are all 10000. I
think it will overflow then?
> +
> +static inline void pagemaps_pmd_range(struct vm_area_struct *vma, pud_t
> *pud,
> + unsigned long addr, unsigned long end,
> + struct seq_file *m)
> +{
> + pmd_t *pmd;
> + unsigned long next;
> +
> + pmd = pmd_offset(pud, addr);
> + do {
> + next = pmd_addr_end(addr, end);
> + if (pmd_none_or_clear_bad(pmd))
> + continue;
> + pagemaps_pte_range(vma, pmd, addr, next, m);
> + } while (pmd++, addr = next, addr != end);
> +}
> +
> +static inline void pagemaps_pud_range(struct vm_area_struct *vma, pgd_t
> *pgd,
> + unsigned long addr, unsigned long end,
> + struct seq_file *m)
> +{
> + pud_t *pud;
> + unsigned long next;
> +
> + pud = pud_offset(pgd, addr);
> + do {
> + next = pud_addr_end(addr, end);
> + if (pud_none_or_clear_bad(pud))
> + continue;
> + pagemaps_pmd_range(vma, pud, addr, next, m);
> + } while (pud++, addr = next, addr != end);
> +}
> +
> +static inline void pagemaps_pgd_range(struct vm_area_struct *vma,
> + unsigned long addr, unsigned long end,
> + struct seq_file *m)
> +{
> + pgd_t *pgd;
> + unsigned long next;
> +
> + pgd = pgd_offset(vma->vm_mm, addr);
> + do {
> + next = pgd_addr_end(addr, end);
> + if (pgd_none_or_clear_bad(pgd))
> + continue;
> + pagemaps_pud_range(vma, pgd, addr, next, m);
> + } while (pgd++, addr = next, addr != end);
> +}
I think that's our eighth open-coded pagetable walker. Apparently they are
all slightly different. Perhaps we shouild do something about that one
day.
--
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 parent reply other threads:[~2006-12-07 22:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <45789124.1070207@mvista.com>
2006-12-07 22:36 ` Andrew Morton [this message]
2006-12-08 0:30 ` david singleton
2006-12-08 1:07 ` david singleton
2006-12-08 1:46 ` Andrew Morton
2006-12-08 1:53 ` david singleton
2006-12-08 6:21 ` Paul Cameron Davies
2006-12-08 21:46 ` Jeremy Fitzhardinge
2006-12-11 2:19 ` Paul Cameron Davies
2006-12-11 8:13 Albert Cahalan
2006-12-12 1:15 ` Joe Green
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=20061207143611.7a2925e2.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=dsingleton@mvista.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