public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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: Sat, 18 Aug 2007 16:45:31 +0800	[thread overview]
Message-ID: <387426732.29114@ustc.edu.cn> (raw)
Message-ID: <20070818084531.GB5277@mail.ustc.edu.cn> (raw)
In-Reply-To: <20070818064042.GQ30556@waste.org>

Matt,

On Sat, Aug 18, 2007 at 01:40:42AM -0500, Matt Mackall wrote:
> > - On memory pressure,
> >   - as VSZ goes up, RSS will be bounded by physical memory.
> >     So VSZ:RSS ratio actually goes up with memory pressure.
> 
> And yes.
> 
> But that's not what I'm talking about. You're likely to have more
> holes in your ranges with memory pressure as things that aren't active
> get paged or swapped out and back in. And because we're walking the
> LRU more rapidly, we'll flip over a lot of the active bits more often
> which will mean more output.
> 
> >   - page range is a good unit of locality. They are more likely to be
> >     reclaimed as a whole. So (RSS:page_ranges) wouldn't degrade as much.
> 
> There is that. The relative magnitude of the different effects is
> unclear. But it is clear that the worst case for pmap is much worse

> than pagemap (two lines per page of RSS?). 
It's one line per page. No sane app will make vmas proliferate.

So let's talk about the worst case.

pagemap's data set size is determined by VSZ.
4GB VSZ means 1M PFNs, hence 8MB pagemap data.

pmaps's data set size is bounded by RSS hence physical memory.
4GB RSS means up to 1M page ranges, hence ~20M pmaps data.
Not too bad :)

> > > But there are still the downsides I have mentioned:
> > > 
> > > - you don't get page frame numbers
> > 
> > True. I guess PFNs are meaningless to a normal user?
> 
> They're useful for anyone who's trying to look at the system as a
> whole.
>  
> > > - you can't do random access
> > 
> > Not for now.
> > 
> > It would be trivial to support seek-by-address semantic: the seqfile
> > operations already iterate by addresses. Only that we cannot do it via
> > the regular read/pread/seek interfaces. They have different semantic
> > on fpos. However, tricks like ioctl(begin_addr, end_addr) can be
> > employed if necessary.
> 
> I suppose. But if you're willing to stomach that sort of thing, you
> might as well use a simple binary interface.

Python can do ioctl() :)

Anyway it's already a special interface.


  reply	other threads:[~2007-08-18  8:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070816220516.782145952@mail.ustc.edu.cn>
2007-08-16 22:05 ` [PATCH 0/4] process memory footprints in proc/<pid>/[s|p]maps Fengguang Wu
     [not found] ` <20070816220849.313377588@mail.ustc.edu.cn>
2007-08-16 22:05   ` [PATCH 3/4] maps: introduce generic_maps_open() Fengguang Wu
     [not found] ` <20070816220849.064901548@mail.ustc.edu.cn>
2007-08-16 22:05   ` [PATCH 1/4] maps: PSS(proportional set size) accounting in smaps Fengguang Wu
2007-08-17  2:13   ` Matt Mackall
     [not found]     ` <20070817024443.GA5521@mail.ustc.edu.cn>
2007-08-17  2:44       ` Fengguang Wu
     [not found] ` <20070816220849.192029043@mail.ustc.edu.cn>
2007-08-16 22:05   ` [PATCH 2/4] maps: address based vma walking Fengguang Wu
2007-08-17  2:16   ` Matt Mackall
     [not found]     ` <20070817025454.GB5521@mail.ustc.edu.cn>
2007-08-17  2:54       ` Fengguang Wu
     [not found] ` <20070816220849.472883642@mail.ustc.edu.cn>
2007-08-16 22:05   ` [PATCH 4/4] maps: /proc/<pid>/pmaps interface - memory maps in granularity of pages Fengguang Wu
2007-08-17  2:38   ` Matt Mackall
     [not found]     ` <20070817034437.GC5521@mail.ustc.edu.cn>
2007-08-17  3:44       ` Fengguang Wu
2007-08-17  3:56       ` Matt Mackall
     [not found]     ` <20070817064727.GA6723@mail.ustc.edu.cn>
2007-08-17  6:47       ` Fengguang Wu
2007-08-17 16:58       ` Matt Mackall
     [not found]         ` <20070818024831.GA7856@mail.ustc.edu.cn>
2007-08-18  2:48           ` Fengguang Wu
2007-08-18  6:40           ` Matt Mackall
     [not found]             ` <20070818084531.GB5277@mail.ustc.edu.cn>
2007-08-18  8:45               ` Fengguang Wu [this message]
2007-08-18 17:22               ` Matt Mackall
     [not found]                 ` <20070819004008.GA5297@mail.ustc.edu.cn>
2007-08-19  0:40                   ` Fengguang Wu
     [not found]             ` <20070818103146.GA6744@mail.ustc.edu.cn>
2007-08-18 10:31               ` Fengguang Wu
     [not found] <20070819075410.411207640@mail.ustc.edu.cn>
     [not found] ` <20070819075547.785390741@mail.ustc.edu.cn>
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=387426732.29114@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox