lkml.org 
[lkml]   [2010]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subject[PATCH][RFC] Fix up rss/swap usage of shm segments in /proc/pid/smaps
> > By the way - I found another bug/issue in /proc/<pid>/smaps as well. The
> > kernel currently does not adds swapped-out shm pages to the swap size value
> > correctly. The swap size value always stays zero for shm pages. I'm currently
> > preparing a small patch to fix that, which I will send to linux-mm for review
> > soon.
>
> I certainly wouldn't call smaps's present behaviour on it a bug: but given
> your justification above, I can see that it would be more useful to you,
> and probably to others, for it to be changed in the way that you suggest,
> to reveal the underlying swap.
>
> Hmm, I wonder what that patch is going to look like...

:-)

I tried quite hard to implement rss/swap accounting for shm segments inside
smaps_pte_range() which is a callback function of walk_page_range() in
show_smap().

Given the fact that I'm no linux-mm expert, I might have overseen other
possibilities, but my experiments inside smaps_pte_range() were not
very successful:
From my tests, a swapped-out shm segment
- fails on the "is_swap_pte()" test, and
- succeeds on the "!pte_present()" test (since it's swapped
out).
So, here would it be possible to add such accounting for swap, but how
can I then see that this pte is
a) belonging to a shm segment?, and
b) see if this page/pte was really swapped out and not just not
yet written to at all?
As answers I found:
a) (vma->vm_flags & VM_MAYSHARE) is true for shm segments (is
this check sufficient?)
b) no idea.

But if I add this page to the mss.swap entry, all pages including such
which haven't been touched yet at all are suddenly counted as
swapped-out...?

Any hints here would be great...


As an alternative solution, I created the following patch.
This one works nicely, but it's just a fix-up of the mss.resident and
mss.swap values after walk_page_range() was called.
It's mostly a copy of the shm_add_rss_swap() function from
my previous patch (http://marc.info/?l=linux-mm&m=128171161101817&w=2).
Do you think such a fix-up-afterwards-approach is acceptable at all?
If yes, a new patch on top of my ipc/shm.c patch would be easy (and
small).

Comments?

Helge



diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index aea1d3f..a1ef7c9 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -9,6 +9,7 @@
#include <linux/mempolicy.h>
#include <linux/swap.h>
#include <linux/swapops.h>
+#include <linux/shmem_fs.h>

#include <asm/elf.h>
#include <asm/uaccess.h>
@@ -392,6 +393,31 @@ static int show_smap(struct seq_file *m, void *v)
if (vma->vm_mm && !is_vm_hugetlb_page(vma))
walk_page_range(vma->vm_start, vma->vm_end, &smaps_walk);

+#ifdef CONFIG_SYSVIPC
+ /* sysvipc shm segments and hugepages are counted wrong in
+ * walk_page_range(). Fix it up.
+ */
+ if (vma->vm_file && (vma->vm_flags & VM_MAYSHARE)) {
+ struct inode *inode = vma->vm_file->f_path.dentry->d_inode;
+ if (is_file_hugepages(vma->vm_file)) {
+ struct address_space *mapping = inode->i_mapping;
+ struct hstate *h = hstate_file(vma->vm_file);
+ mss.resident = pages_per_huge_page(h) *
+ mapping->nrpages * PAGE_SIZE;
+ } else {
+#ifdef CONFIG_SHMEM
+ struct shmem_inode_info *info = SHMEM_I(inode);
+ spin_lock(&info->lock);
+ mss.resident = inode->i_mapping->nrpages * PAGE_SIZE;
+ mss.swap = info->swapped * PAGE_SIZE;
+ spin_unlock(&info->lock);
+#else
+ mss.resident = inode->i_mapping->nrpages * PAGE_SIZE;
+#endif
+ }
+ }
+#endif
+
show_map_vma(m, vma);

seq_printf(m,

\
 
 \ /
  Last update: 2010-08-13 21:55    [W:0.055 / U:0.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site