maps: introduce generic_maps_open()

The "proportional set size" (PSS) of a process is the count of pages it has in memory, where each page is divided by the number of processes sharing it. So if a process has 1000 pages all to itself, and 1000 shared with one other process, its PSS will be 1500.
- lwn.net: "ELC: How much memory are applications really using?"

The PSS proposed by Matt Mackall is a very nice metic for measuring an process's memory footprint. So collect and export it via /proc/<pid>/smaps.

Matt Mackall's pagemap/kpagemap and John Berthels's exmap can also do the job. They are comprehensive tools. But for PSS, let's do it in the simple way.

Quoted 9 lines · Fengguang Wu

The "proportional set size" (PSS) of a process is the count of pages it has in memory, where each page is divided by the number of processes sharing it. So if a process has 1000 pages all to itself, and 1000 shared with one other process, its PSS will be 1500.
- lwn.net: "ELC: How much memory are applications really using?"

The PSS proposed by Matt Mackall is a very nice metic for measuring an process's memory footprint. So collect and export it via /proc/<pid>/smaps.

Quoted 2 lines

Matt Mackall's pagemap/kpagemap and John Berthels's exmap can also do the job. They are comprehensive tools. But for PSS, let's do it in the simple way.

It's a bit odd that you attribute the description of PSS to LWN rather than me. But anyway:

Acked-by Matt Mackall <[email protected]>

Split large vmas into page groups of proc_maps_private.batch_size bytes, and iterate them one by one for seqfile->show. This allows us to export large scale process address space information via the seqfile interface. The old behavior of walking one vma at a time can be achieved by setting the batching size to ~0UL.

Cc Matt Mackall <[email protected]>

Cc Al Viro <[email protected]>

Signed-off-by Fengguang Wu <[email protected]>

---
 fs/proc/task_mmu.c      |  105 ++++++++++++--------------------------
 include/linux/proc_fs.h |    6 +-
 mm/mempolicy.c          |    2 
 3 files changed, 38 insertions(+), 75 deletions(-)

include/linux/proc_fs.h +3 -3

@@ -283,9 +283,9 @@ static inline struct proc_dir_entry *PDE
 struct proc_maps_private {
 	struct pid *pid;
 	struct task_struct *task;
-#ifdef CONFIG_MMU
-	struct vm_area_struct *tail_vma;
-#endif
+	struct mm_struct *mm;
+	/* walk min(batch_size, remaining_size_of(vma)) bytes at a time */
+	unsigned long batch_size;
 };
 
 #endif /* _LINUX_PROC_FS_H */

fs/proc/task_mmu.c +35 -70

@@ -115,99 +115,65 @@ static void pad_len_spaces(struct seq_fi
 	seq_printf(m, "%*c", len, ' ');
 }
 
-static void vma_stop(struct proc_maps_private *priv, struct vm_area_struct *vma)
+static void *seek_vma_addr(struct seq_file *m,
+			   struct vm_area_struct *vma, loff_t *pos)
 {
-	if (vma && vma != priv->tail_vma) {
-		struct mm_struct *mm = vma->vm_mm;
-		up_read(&mm->mmap_sem);
-		mmput(mm);
-	}
+	struct proc_maps_private *priv = m->private;
+	unsigned long addr = *pos;
+
+	if (addr & ~PAGE_MASK) { /* time for next batch */
+		if (vma->vm_end - addr < priv->batch_size) {
+			vma = vma->vm_next;
+			if (!vma || vma == get_gate_vma(priv->task))
+				goto done;
+		} else
+			addr = (addr + priv->batch_size) & PAGE_MASK;
+	}
+	if (addr < vma->vm_start)
+	    addr = vma->vm_start;
+
+	m->version = *pos = addr;
+	return vma;
+done:
+	return NULL;
 }
 
 static void *m_start(struct seq_file *m, loff_t *pos)
 {
 	struct proc_maps_private *priv = m->private;
-	unsigned long last_addr = m->version;
-	struct mm_struct *mm;
-	struct vm_area_struct *vma, *tail_vma = NULL;
-	loff_t l = *pos;
-
-	/* Clear the per syscall fields in priv */
-	priv->task = NULL;
-	priv->tail_vma = NULL;
-
-	/*
-	 * We remember last_addr rather than next_addr to hit with
-	 * mmap_cache most of the time. We have zero last_addr at
-	 * the beginning and also after lseek. We will have -1 last_addr
-	 * after the end of the vmas.
-	 */
-
-	if (last_addr == -1UL)
-		return NULL;
+	struct vm_area_struct *vma;
 
+	priv->mm = NULL;
 	priv->task = get_pid_task(priv->pid, PIDTYPE_PID);
 	if (!priv->task)
 		return NULL;
 
-	mm = get_task_mm(priv->task);
-	if (!mm)
+	priv->mm = get_task_mm(priv->task);
+	if (!priv->mm)
 		return NULL;
 
-	priv->tail_vma = tail_vma = get_gate_vma(priv->task);
-	down_read(&mm->mmap_sem);
+	down_read(&priv->mm->mmap_sem);
 
-	/* Start with last addr hint */
-	if (last_addr && (vma = find_vma(mm, last_addr))) {
-		vma = vma->vm_next;
-		goto out;
-	}
-
-	/*
-	 * Check the vma index is within the range and do
-	 * sequential scan until m_index.
-	 */
-	vma = NULL;
-	if ((unsigned long)l < mm->map_count) {
-		vma = mm->mmap;
-		while (l-- && vma)
-			vma = vma->vm_next;
-		goto out;
-	}
-
-	if (l != mm->map_count)
-		tail_vma = NULL; /* After gate vma */
-
-out:
-	if (vma)
-		return vma;
+	vma = find_vma(priv->mm, *pos);
+	if (!vma || vma == get_gate_vma(priv->task))
+		return NULL;
 
-	/* End of vmas has been reached */
-	m->version = (tail_vma != NULL)? 0: -1UL;
-	up_read(&mm->mmap_sem);
-	mmput(mm);
-	return tail_vma;
+	return seek_vma_addr(m, vma, pos);
 }
 
 static void *m_next(struct seq_file *m, void *v, loff_t *pos)
 {
-	struct proc_maps_private *priv = m->private;
-	struct vm_area_struct *vma = v;
-	struct vm_area_struct *tail_vma = priv->tail_vma;
-
 	(*pos)++;
-	if (vma && (vma != tail_vma) && vma->vm_next)
-		return vma->vm_next;
-	vma_stop(priv, vma);
-	return (vma != tail_vma)? tail_vma: NULL;
+	return seek_vma_addr(m, v, pos);
 }
 
 static void m_stop(struct seq_file *m, void *v)
 {
 	struct proc_maps_private *priv = m->private;
-	struct vm_area_struct *vma = v;
-
-	vma_stop(priv, vma);
+	if (priv->mm) {
+		up_read(&priv->mm->mmap_sem);
+		mmput(priv->mm);
+	}
 	if (priv->task)
 		put_task_struct(priv->task);
 }

@@ -220,6 +186,7 @@ static int do_maps_open(struct inode *in
 	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
 	if (priv) {
 		priv->pid = proc_pid(inode);
+		priv->batch_size = ~0;
 		ret = seq_open(file, ops);
 		if (!ret) {
 			struct seq_file *m = file->private_data;

@@ -291,8 +258,6 @@ static int show_map(struct seq_file *m, 
 	}
 	seq_putc(m, '\n');
 
-	if (m->count < m->size)  /* vma is copied successfully */
-		m->version = (vma != get_gate_vma(task))? vma->vm_start: 0;
 	return 0;
 }

Quoted 36 lines · Fengguang Wu

Split large vmas into page groups of proc_maps_private.batch_size bytes, and iterate them one by one for seqfile->show. This allows us to export large scale process address space information via the seqfile interface. The old behavior of walking one vma at a time can be achieved by setting the batching size to ~0UL.

Cc Matt Mackall <[email protected]>

Cc Al Viro <[email protected]>

Signed-off-by Fengguang Wu <[email protected]>

---
 fs/proc/task_mmu.c      |  105 ++++++++++++--------------------------
 include/linux/proc_fs.h |    6 +-
 mm/mempolicy.c          |    2 
 3 files changed, 38 insertions(+), 75 deletions(-)

include/linux/proc_fs.h +3 -3

@@ -283,9 +283,9 @@ static inline struct proc_dir_entry *PDE
 struct proc_maps_private {
 	struct pid *pid;
 	struct task_struct *task;
-#ifdef CONFIG_MMU
-	struct vm_area_struct *tail_vma;
-#endif
+	struct mm_struct *mm;
+	/* walk min(batch_size, remaining_size_of(vma)) bytes at a time */
+	unsigned long batch_size;
 };
 
 #endif /* _LINUX_PROC_FS_H */

mm/mempolicy.c +0 -0

@@ -1937,7 +1937,5 @@ out:
 	seq_putc(m, '\n');
 	kfree(md);
 

mm/mempolicy.c out: · line 1941

Quoted 4 lines

mm/mempolicy.c +0 -2

-	if (m->count < m->size)
-		m->version = (vma != priv->tail_vma) ? vma->vm_start : 0;
 	return 0;
 }

What's this bit for?

Show a process's page-by-page address space infomation in /proc/<pid>/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
- number of pages in the range
- well known page/pte flags
- number of mmap users

Only page flags not expected to disappear in the near future are exported:

Y:young R:referenced A:active U:uptodate P:ptedirty D:dirty W:writeback

The concern of dataset size is taken care of by working in a sparse way:

1) It will only generate output for resident pages, that normally is much smaller than the mapped size. Take my shell for example, the (size:rss) ratio is (7:1)!

wfg ~% cat /proc/$$/smaps |grep Size|sum
sum 50552.000
avg 777.723

wfg ~% cat /proc/$$/smaps |grep Rss|sum
sum 7604.000
avg 116.985

2) The page range trick suppresses more output.

It's interesting to see that the seq_file interface demands some more programming efforts, and provides such flexibility as well.

Quoted 13 lines · Fengguang Wu

Show a process's page-by-page address space infomation in /proc/<pid>/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
- number of pages in the range
- well known page/pte flags
- number of mmap users

Only page flags not expected to disappear in the near future are exported:

Y:young R:referenced A:active U:uptodate P:ptedirty D:dirty W:writeback

...

Quoted 14 lines

The concern of dataset size is taken care of by working in a sparse way:

1) It will only generate output for resident pages, that normally is much smaller than the mapped size. Take my shell for example, the (size:rss) ratio is (7:1)!

wfg ~% cat /proc/$$/smaps |grep Size|sum
sum 50552.000
avg 777.723

wfg ~% cat /proc/$$/smaps |grep Rss|sum
sum 7604.000
avg 116.985

Quoted 4 lines

2) The page range trick suppresses more output.

It's interesting to see that the seq_file interface demands some more programming efforts, and provides such flexibility as well.

I'm so-so on this.

On the downside:

- requires lots of parsing
- isn't random-access
- probably significantly slower than pagemap

Quoted 1 line

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.

Quoted 5 lines

On the downside:

- requires lots of parsing
- isn't random-access
- probably significantly slower than pagemap

That could be true. Maybe some user with huge datasets will give us some idea about the performance. I don't know, maybe it's application dependent.

Anyway I don't think it's fair to merge a binary interface without the challenge from a textual one ;)

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 :)

Quoted 7 lines · Fengguang Wu

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

Quoted 6 lines

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

I take it you're in 64-bit mode?

You're right, this data compresses well in many circumstances. I suspect it will suffer under memory pressure though. That will fragment the ranges in-memory and also fragment the active bits. The worst case here is huge, of course, but realistically I'd expect something like 2x-4x.

But there are still the downsides I have mentioned:

- you don't get page frame numbers

- you can't do random access

And how long does it take to pull the data out? My benchmarks show greater than 50MB/s (and that's with the version in -mm that's doing double buffering), so that 800K would take < .016s.

Quoted 7 lines

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)

You can do anywhere between 16k small reads or 1 large read. Depends

what data you're trying to get. Right now, kpagemap is fast enough that I can do realtime displays of the whole of memory in my desktop in a GUI written in Python. And Python is fairly horrible for drawing bitmaps and such.

http://www.selenic.com/Screenshot-kpagemap.png

Quoted 1 line

So pmaps seems to be a clear winner :)

Except that it's only providing a subset of the data.

Matt,

Quoted 8 lines · Matt Mackall

Quoted 7 lines · Fengguang Wu

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

Quoted 8 lines

Quoted 6 lines

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

I take it you're in 64-bit mode?

Yes. That will be the common case.

Quoted 5 lines

You're right, this data compresses well in many circumstances. I suspect it will suffer under memory pressure though. That will fragment the ranges in-memory and also fragment the active bits. The worst case here is huge, of course, but realistically I'd expect something like 2x-4x.

Not likely to degrade even under memory pressure ;)

The compress_ratio = (VSZ:RSS) * (RSS:page_ranges).
- On fresh startup and no memory pressure,
- the VSZ:RSS ratio of ALL processes are 4516796KB:457048KB ~= 10:1.
- the firefox case shows a (RSS:page_ranges) of 16k:2k ~= 8:1.

- On memory pressure,
- as VSZ goes up, RSS will be bounded by physical memory. So VSZ:RSS ratio actually goes up with memory pressure.

- 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.

Quoted 3 lines

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?

Quoted 1 line

- 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.

Quoted 3 lines

- 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.

Quoted 2 lines

- 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?).

Quoted 5 lines

Quoted 3 lines

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.

Quoted 4 lines

Quoted 1 line

- you can't do random access

Not for now.

Quoted 5 lines

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.

Quoted 3 lines

Quoted 1 line

- 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.

Matt,

Quoted 12 lines · Matt Mackall

Quoted 3 lines

- 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.

Quoted 7 lines

Quoted 2 lines

- 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 :)

Quoted 13 lines

Quoted 13 lines

Quoted 1 line

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.

Quoted 2 lines

- 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.

Quoted 5 lines

Quoted 4 lines

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.

Sane apps are few and far between.

Quoted 5 lines

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.

Quoted 3 lines

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 :)

Hmmm, I've been misreading the output.

What does it do with nonlinear VMAs?