Show a process's page-by-page address space infomation in /proc//pmaps.
It helps to analyze application memory footprints in a comprehensive way.
Pages share the same states are grouped into a page range.
For each page range, the following fields are exported:
- [HEX NUM] first page index
On Sat, Aug 18, 2007 at 12:22:26PM -0500, Matt Mackall wrote:
> > > > 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
On Sat, Aug 18, 2007 at 04:45:31PM +0800, Fengguang Wu wrote:
> 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.
>
On Sat, Aug 18, 2007 at 01:40:42AM -0500, Matt Mackall wrote:
> > > - 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.
To answer the question: "who are sharing this page
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
On Sat, Aug 18, 2007 at 10:48:31AM +0800, Fengguang Wu wrote:
> Matt,
>
> On Fri, Aug 17, 2007 at 11:58:08AM -0500, Matt Mackall wrote:
> > On Fri, Aug 17, 2007 at 02:47:27PM +0800, Fengguang Wu wrote:
> > > It's not easy to do direct performance comparisons between pmaps and
> > >
Matt,
On Fri, Aug 17, 2007 at 11:58:08AM -0500, Matt Mackall wrote:
> On Fri, Aug 17, 2007 at 02:47:27PM +0800, Fengguang Wu wrote:
> > It's not easy to do direct performance comparisons between pmaps and
> > pagemap/kpagemap. However some close analyzes are still possible :)
> >
> > 1) code
On Fri, Aug 17, 2007 at 02:47:27PM +0800, Fengguang Wu wrote:
> 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
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
On Fri, Aug 17, 2007 at 11:44:37AM +0800, Fengguang Wu wrote:
> > I'm so-so on this.
>
> Not that way! It's a good thing that people have different experiences
> and hence viewpoints. Maybe the concept of PFN sharing are
> straightforward to you, while I have been playing with seq_file a lot.
>
On Thu, Aug 16, 2007 at 09:38:46PM -0500, Matt Mackall wrote:
> On Fri, Aug 17, 2007 at 06:05:20AM +0800, Fengguang Wu wrote:
> > Show a process's page-by-page address space infomation in /proc//pmaps.
> > It helps to analyze applications' memory footprints in a comprehensive way.
> >
> > Pages
On Fri, Aug 17, 2007 at 06:05:20AM +0800, Fengguang Wu wrote:
> Show a process's page-by-page address space infomation in /proc//pmaps.
> It helps to analyze applications' memory footprints in a comprehensive way.
>
> Pages share the same states are grouped into a page range.
> For each page
Show a process's page-by-page address space infomation in /proc//pmaps.
It helps to analyze applications' memory footprints in a comprehensive way.
Pages share the same states are grouped into a page range.
For each page range, the following fields are exported:
- first page index
13 matches
Mail list logo
