public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mauricio Lin <mauriciolin@gmail.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] A new entry for /proc
Date: Fri, 14 Jan 2005 18:46:11 -0400	[thread overview]
Message-ID: <3f250c7105011414466f22fc37@mail.gmail.com> (raw)
In-Reply-To: <20050106202339.4f9ba479.akpm@osdl.org>

Hi All,

> > + extern struct seq_operations proc_pid_smaps_op;
> 
>   Put extern headers in .h files, not in .c.

Andrew, I did not put the extern headers in .h files, because I
noticed that there are other extern headers in base.c, so I think
would be better follow the code style. If it is necessary to put it in
.h file, which file do I have to put (or create a new one)?

Here goes the new PATCH.

**************************************
PATCH
**************************************

diff -urN linux-2.6.10/fs/proc/base.c linux-2.6.10-smaps/fs/proc/base.c
--- linux-2.6.10/fs/proc/base.c	2004-12-24 17:35:00.000000000 -0400
+++ linux-2.6.10-smaps/fs/proc/base.c	2005-01-14 17:07:30.000000000 -0400
@@ -11,6 +11,18 @@
  *  go into icache. We cache the reference to task_struct upon lookup too.
  *  Eventually it should become a filesystem in its own. We don't use the
  *  rest of procfs anymore.
+ *
+ *
+ *  2005
+ *  Allan Bezerra
+ *  Bruna Moreira <bruna.moreira@indt.org.br>
+ *  Edjard Mota <edjard.mota@indt.org.br>
+ *  Ilias Biris <ext-ilias.biris@indt.org.br>
+ *  Mauricio Lin <mauricio.lin@indt.org.br>
+ *
+ *  Embedded Linux Lab - 10LE Instituto Nokia de Tecnologia - INdT
+ *
+ *  A new entry smaps included in /proc. It shows the size of rss for
each memory area.
  */
 
 #include <asm/uaccess.h>
@@ -60,6 +72,7 @@
 	PROC_TGID_MAPS,
 	PROC_TGID_MOUNTS,
 	PROC_TGID_WCHAN,
+	PROC_TGID_SMAPS,
 #ifdef CONFIG_SCHEDSTATS
 	PROC_TGID_SCHEDSTAT,
 #endif
@@ -86,6 +99,7 @@
 	PROC_TID_MAPS,
 	PROC_TID_MOUNTS,
 	PROC_TID_WCHAN,
+	PROC_TID_SMAPS,
 #ifdef CONFIG_SCHEDSTATS
 	PROC_TID_SCHEDSTAT,
 #endif
@@ -123,6 +137,7 @@
 	E(PROC_TGID_ROOT,      "root",    S_IFLNK|S_IRWXUGO),
 	E(PROC_TGID_EXE,       "exe",     S_IFLNK|S_IRWXUGO),
 	E(PROC_TGID_MOUNTS,    "mounts",  S_IFREG|S_IRUGO),
+	E(PROC_TGID_SMAPS,     "smaps",   S_IFREG|S_IRUGO),
 #ifdef CONFIG_SECURITY
 	E(PROC_TGID_ATTR,      "attr",    S_IFDIR|S_IRUGO|S_IXUGO),
 #endif
@@ -148,6 +163,7 @@
 	E(PROC_TID_ROOT,       "root",    S_IFLNK|S_IRWXUGO),
 	E(PROC_TID_EXE,        "exe",     S_IFLNK|S_IRWXUGO),
 	E(PROC_TID_MOUNTS,     "mounts",  S_IFREG|S_IRUGO),
+	E(PROC_TID_SMAPS,      "smaps",   S_IFREG|S_IRUGO),
 #ifdef CONFIG_SECURITY
 	E(PROC_TID_ATTR,       "attr",    S_IFDIR|S_IRUGO|S_IXUGO),
 #endif
@@ -497,6 +513,25 @@
 	.release	= seq_release,
 };
 
+extern struct seq_operations proc_pid_smaps_op;
+static int smaps_open(struct inode *inode, struct file *file)
+{
+	struct task_struct *task = proc_task(inode);
+	int ret = seq_open(file, &proc_pid_smaps_op);
+	if (!ret) {
+		struct seq_file *m = file->private_data;
+		m->private = task;
+	}
+	return ret;
+}
+
+static struct file_operations proc_smaps_operations = {
+	.open		= smaps_open,
+	.read		= seq_read,
+	.llseek		= seq_lseek,
+	.release	= seq_release,
+};
+
 extern struct seq_operations mounts_op;
 static int mounts_open(struct inode *inode, struct file *file)
 {
@@ -1341,6 +1376,11 @@
 		case PROC_TGID_MOUNTS:
 			inode->i_fop = &proc_mounts_operations;
 			break;
+		case PROC_TID_SMAPS:
+		case PROC_TGID_SMAPS:
+			inode->i_fop = &proc_smaps_operations;
+			break;
+
 #ifdef CONFIG_SECURITY
 		case PROC_TID_ATTR:
 			inode->i_nlink = 2;
diff -urN linux-2.6.10/fs/proc/task_mmu.c linux-2.6.10-smaps/fs/proc/task_mmu.c
--- linux-2.6.10/fs/proc/task_mmu.c	2004-12-24 17:34:01.000000000 -0400
+++ linux-2.6.10-smaps/fs/proc/task_mmu.c	2005-01-14 16:35:38.000000000 -0400
@@ -81,6 +81,72 @@
 	return 0;
 }
 
+static void resident_mem_size(struct mm_struct *mm, unsigned long
start_address,
+			unsigned long end_address, unsigned long *size) {
+	pgd_t *pgd;
+	pmd_t *pmd;
+	pte_t *ptep, pte;
+	unsigned long each_page;
+
+	for (each_page = start_address; each_page < end_address; each_page
+= PAGE_SIZE) {
+		pgd = pgd_offset(mm, each_page);
+		if (pgd_none(*pgd) || unlikely(pgd_bad(*pgd)))
+			continue;
+
+		pmd = pmd_offset(pgd, each_page);
+
+		if (pmd_none(*pmd))
+			continue;
+
+		if (unlikely(pmd_bad(*pmd)))
+			continue;
+
+		if (pmd_present(*pmd)) {
+			ptep = pte_offset_map(pmd, each_page);
+			if (!ptep)
+				continue;
+			pte = *ptep;
+			pte_unmap(ptep);
+			if (pte_present(pte))
+				*size += PAGE_SIZE;
+		}
+	}
+}
+
+static int show_smap(struct seq_file *m, void *v)
+{
+	struct vm_area_struct *map = v;
+	struct file *file = map->vm_file;
+	int flags = map->vm_flags;
+	struct mm_struct *mm = map->vm_mm;
+	unsigned long rss = 0;
+	unsigned long vma_len = (map->vm_end - map->vm_start) >> 10;
+	
+	if (mm) {
+		resident_mem_size(mm, map->vm_start, map->vm_end, &rss);
+	}
+
+	seq_printf(m, "%08lx-%08lx %c%c%c%c ",
+			map->vm_start,
+			map->vm_end,
+			flags & VM_READ ? 'r' : '-',
+			flags & VM_WRITE ? 'w' : '-',
+			flags & VM_EXEC ? 'x' : '-',
+			flags & VM_MAYSHARE ? 's' : 'p');
+
+	if (map->vm_file)
+		seq_path(m, file->f_vfsmnt, file->f_dentry, " \t\n\\");
+
+	seq_putc(m, '\n');
+	
+	seq_printf(m, "Size:%8lu kB\n"
+			"Rss:%8lu kB\n",
+			vma_len,
+			rss >> 10);
+	
+	return 0;
+}
+
 static void *m_start(struct seq_file *m, loff_t *pos)
 {
 	struct task_struct *task = m->private;
@@ -134,3 +200,10 @@
 	.stop	= m_stop,
 	.show	= show_map
 };
+
+struct seq_operations proc_pid_smaps_op = {
+	.start	= m_start,
+	.next	= m_next,
+	.stop	= m_stop,
+	.show	= show_smap
+};


The smaps was used to verify the memory consumption of gecko rendering
engine and has presented interesting results in a detailed way. Below
is the link to access the graphics generated by the application that
reads from /proc/pid/smaps.

http://www.manaos.org/10le/smaps.html

BR,

Mauricio Lin.

  parent reply	other threads:[~2005-01-14 22:47 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-06 21:11 [PATCH] A new entry for /proc Mauricio Lin
2005-01-07  4:23 ` Andrew Morton
2005-01-07 12:30   ` Roger Luethi
2005-01-08 20:20   ` Hugh Dickins
2005-01-08 21:47     ` Alan Cox
2005-01-10  9:21     ` Edjard Souza Mota
2005-01-10 15:23     ` Mauricio Lin
2005-02-22 13:13     ` Mauricio Lin
2005-02-24  8:31       ` Mauricio Lin
2005-02-24  9:09         ` Andrew Morton
2005-02-24 11:43           ` Mauricio Lin
2005-02-24 11:52             ` Andrew Morton
2005-02-25 15:14               ` Mauricio Lin
2005-02-28  9:43                 ` Mauricio Lin
2005-02-28  9:56                   ` Mauricio Lin
2005-02-28 20:41                     ` Hugh Dickins
2005-03-01  8:08                       ` Mauricio Lin
2005-03-01 14:17                         ` Mauricio Lin
2005-03-01 15:44                           ` Mauricio Lin
2005-03-02 12:20                             ` Mauricio Lin
2005-03-02 19:07                               ` Hugh Dickins
2005-03-03  7:25                                 ` Mauricio Lin
2005-03-03 12:48                                   ` Hugh Dickins
2005-03-03 14:23                                     ` Mauricio Lin
2005-01-10 14:35   ` Mauricio Lin
2005-01-14 22:46   ` Mauricio Lin [this message]
     [not found]     ` <20050114154209.6b712e55.akpm@osdl.org>
2005-01-17 18:03       ` Mauricio Lin
2005-01-17 19:02         ` Mauricio Lin
2005-01-17 17:30           ` Marcelo Tosatti
2005-01-17 21:27             ` Mauricio Lin
2005-01-17 21:35             ` William Lee Irwin III
2005-01-18  1:07               ` Nick Piggin
2005-01-19 12:59                 ` Nick Piggin
2005-01-24 22:14             ` Mauricio Lin
2005-04-29 18:36   ` Mauricio Lin
2005-04-30  1:25     ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2005-02-24 18:56 Albert Cahalan
2005-03-01 14:32 ` Mauricio Lin

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=3f250c7105011414466f22fc37@mail.gmail.com \
    --to=mauriciolin@gmail.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    /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