From: Fengguang Wu <wfg@mail.ustc.edu.cn>
To: Matt Mackall <mpm@selenic.com>
Cc: Andrew Morton <akpm@osdl.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
David Rientjes <rientjes@google.com>,
John Berthels <jjberthels@gmail.com>,
Nick Piggin <nickpiggin@yahoo.com.au>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] maps: /proc/<pid>/pmaps interface - memory maps in granularity of pages
Date: Fri, 17 Aug 2007 14:47:27 +0800 [thread overview]
Message-ID: <387333248.08272@ustc.edu.cn> (raw)
Message-ID: <20070817064727.GA6723@mail.ustc.edu.cn> (raw)
In-Reply-To: <20070817023846.GJ30556@waste.org>
Matt,
It's not easy to do direct performance comparisons between pmaps and
pagemap/kpagemap. However some close analyzes are still possible :)
1) code size
pmaps ~200 LOC
pagemap/kpagemap ~300 LOC
2) dataset size
take for example my running firefox on Intel Core 2:
VSZ 400 MB
RSS 64 MB, or 16k pages
pmaps 64 KB, wc shows 2k lines, or so much page ranges
pagemap 800 KB, could be heavily optimized by returning partial data
kpagemap 256 KB
3) runtime overheads
pmaps 2k lines of string processing(encode/decode)
kpagemap 16k seek()/read()s, and context switches (could be
optimized somehow by doing a PFN sort first, but
that's also non-trivial overheads)
So pmaps seems to be a clear winner :)
Thank you,
Fengguang
next prev parent reply other threads:[~2007-08-17 6:47 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-16 22:05 [PATCH 0/4] process memory footprints in proc/<pid>/[s|p]maps Fengguang Wu
2007-08-16 22:05 ` Fengguang Wu
2007-08-16 22:05 ` [PATCH 1/4] maps: PSS(proportional set size) accounting in smaps Fengguang Wu
2007-08-16 22:05 ` Fengguang Wu
2007-08-17 2:13 ` Matt Mackall
2007-08-17 2:44 ` Fengguang Wu
2007-08-17 2:44 ` Fengguang Wu
2007-08-16 22:05 ` [PATCH 2/4] maps: address based vma walking Fengguang Wu
2007-08-16 22:05 ` Fengguang Wu
2007-08-17 2:16 ` Matt Mackall
2007-08-17 2:54 ` Fengguang Wu
2007-08-17 2:54 ` Fengguang Wu
2007-08-16 22:05 ` [PATCH 3/4] maps: introduce generic_maps_open() Fengguang Wu
2007-08-16 22:05 ` Fengguang Wu
2007-08-16 22:05 ` [PATCH 4/4] maps: /proc/<pid>/pmaps interface - memory maps in granularity of pages Fengguang Wu
2007-08-16 22:05 ` Fengguang Wu
2007-08-17 2:38 ` Matt Mackall
2007-08-17 3:44 ` Fengguang Wu
2007-08-17 3:44 ` Fengguang Wu
2007-08-17 3:56 ` Matt Mackall
2007-08-17 6:47 ` Fengguang Wu [this message]
2007-08-17 6:47 ` Fengguang Wu
2007-08-17 16:58 ` Matt Mackall
2007-08-18 2:48 ` Fengguang Wu
2007-08-18 2:48 ` Fengguang Wu
2007-08-18 6:40 ` Matt Mackall
2007-08-18 8:45 ` Fengguang Wu
2007-08-18 8:45 ` Fengguang Wu
2007-08-18 17:22 ` Matt Mackall
2007-08-19 0:40 ` Fengguang Wu
2007-08-19 0:40 ` Fengguang Wu
2007-08-18 10:31 ` Fengguang Wu
2007-08-18 10:31 ` Fengguang Wu
-- strict thread matches above, loose matches on Subject: below --
2007-08-19 7:54 [PATCH 0/4] process memory footprint info in proc/<pid>/[s|p]maps v2 Fengguang Wu
2007-08-19 7:54 ` [PATCH 4/4] maps: /proc/<pid>/pmaps interface - memory maps in granularity of pages Fengguang Wu
2007-08-19 7:54 ` Fengguang Wu
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=387333248.08272@ustc.edu.cn \
--to=wfg@mail.ustc.edu.cn \
--cc=akpm@osdl.org \
--cc=jeremy@goop.org \
--cc=jjberthels@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=nickpiggin@yahoo.com.au \
--cc=rientjes@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.