linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* find_vma() cachehit rate
@ 2004-11-21  9:54 Michael Buesch
  2004-11-22  7:10 ` Nick Piggin
  0 siblings, 1 reply; 3+ messages in thread
From: Michael Buesch @ 2004-11-21  9:54 UTC (permalink / raw)
  To: Linux-MM


[-- Attachment #1.1: Type: text/plain, Size: 905 bytes --]

Hi,

I just saw this comment in find_vma():
  /* Check the cache first. */
  /* (Cache hit rate is typically around 35%.) */

I just wanted to play around a bit. Just for fun.
So I wrote the attached patch to collect find_vma()
statistics. I was wondering why my cache hit rate is around
60%. It's always between 55 and 65 percent. Depending on
the workload.
Is this on obsolete comment from the 2.4 days, maybe?

mb@lfs:~$ cat /proc/findvma_stat 
findvma_stat_cachehit  == 356524
findvma_stat_cachemiss == 248728
findvma_stat_fail      == 0
cachehit percentage    == 58%
cachemiss percentage   == 41%
fail percentage        == 0%

My kernel is:
mb@lfs:~$ uname -r
2.6.10-rc2-ck2-nozeroram-findvmastat

If you are interrested to comment on this, please CC: me,
as I'm not subscribed to this mailing list. Thanks.

-- 
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]



[-- Attachment #1.2: find_vma_stat.diff --]
[-- Type: text/x-diff, Size: 4760 bytes --]

Index: mm/mmap.c
===================================================================
RCS file: /home/mb/develop/linux/rsync/linux-2.5/mm/mmap.c,v
retrieving revision 1.149
diff -u -p -r1.149 mmap.c
--- mm/mmap.c	28 Oct 2004 15:17:10 -0000	1.149
+++ mm/mmap.c	20 Nov 2004 22:14:27 -0000
@@ -23,6 +23,7 @@
 #include <linux/mount.h>
 #include <linux/mempolicy.h>
 #include <linux/rmap.h>
+#include <linux/proc_fs.h>
 
 #include <asm/uaccess.h>
 #include <asm/cacheflush.h>
@@ -34,6 +35,12 @@
  */
 #undef DEBUG_MM_RB
 
+/* enable/disable find_vma() statistics.
+ * 1 => enabled
+ * 0 => disabled
+ */
+#define MMAP_FINDVMA_STATS	1
+
 /* description of effects of mapping type and prot in current implementation.
  * this is due to the limited x86 page protection hardware.  The expected
  * behavior is in parens:
@@ -1246,6 +1253,123 @@ get_unmapped_area(struct file *file, uns
 
 EXPORT_SYMBOL(get_unmapped_area);
 
+#if MMAP_FINDVMA_STATS != 0
+static spinlock_t findvma_stat_lock = SPIN_LOCK_UNLOCKED;
+static unsigned long findvma_stat_cachehit;
+static unsigned long findvma_stat_cachemiss;
+static unsigned long findvma_stat_fail;
+static struct proc_dir_entry *findvma_stat_proc;
+
+static int findvma_stat_read(char *buf, char **start, off_t offset, int size, int *eof, void *data)
+{
+	int written;
+	unsigned long total = findvma_stat_cachehit + findvma_stat_cachemiss + findvma_stat_fail;
+	unsigned long hit_percent = findvma_stat_cachehit * 100 / total;
+	unsigned long miss_percent = findvma_stat_cachemiss * 100 / total;
+	unsigned long fail_percent = findvma_stat_fail * 100 / total;
+
+	spin_lock(&findvma_stat_lock);
+	written = snprintf(buf, size, "findvma_stat_cachehit  == %lu\n"
+				      "findvma_stat_cachemiss == %lu\n"
+				      "findvma_stat_fail      == %lu\n"
+				      "cachehit percentage    == %lu%%\n"
+				      "cachemiss percentage   == %lu%%\n"
+				      "fail percentage        == %lu%%\n",
+			   findvma_stat_cachehit,
+			   findvma_stat_cachemiss,
+			   findvma_stat_fail,
+			   hit_percent,
+			   miss_percent,
+			   fail_percent);
+	spin_unlock(&findvma_stat_lock);
+	*eof = 1;
+	return written;
+}
+
+static int findvma_stat_write(struct file *f, const char __user *buf, unsigned long cnt, void *data)
+{
+	int ret = -EINVAL;
+	char *kbuf;
+
+	if (cnt < 1)
+		goto out;
+
+	kbuf = kmalloc(cnt, GFP_KERNEL);
+	if (!kbuf) {
+		ret = -ENOMEM;
+		goto out;
+	}
+	if (copy_from_user(kbuf, buf, cnt)) {
+		ret = -EFAULT;
+		goto out_free;
+	}
+	if (*kbuf == 'c') {
+		/* clear find_vma() statistics. */
+		spin_lock(&findvma_stat_lock);
+		findvma_stat_cachehit = 0;
+		findvma_stat_cachemiss = 0;
+		findvma_stat_fail = 0;
+		spin_unlock(&findvma_stat_lock);
+		ret = cnt;
+	}
+out_free:
+	kfree(kbuf);
+out:
+	return ret;
+}
+
+static void findvma_stat_init(void)
+{
+	static int already_tried = 0;
+	if (already_tried)
+		return;
+	printk("initializing find_vma() statistics... ");
+	findvma_stat_proc = create_proc_entry("findvma_stat", S_IRUGO | S_IWUSR, 0);
+	if (!findvma_stat_proc) {
+		printk("FAILED.\n");
+		already_tried = 1;
+		return;
+	}
+	findvma_stat_proc->read_proc = findvma_stat_read;
+	findvma_stat_proc->write_proc = findvma_stat_write;
+	findvma_stat_proc->data = 0;
+	printk("Ok.\n");
+}
+
+static inline void findvma_stat_inc_cachehit(void)
+{
+	spin_lock(&findvma_stat_lock);
+	if (!findvma_stat_proc)
+		findvma_stat_init();
+	findvma_stat_cachehit++;
+	spin_unlock(&findvma_stat_lock);
+}
+
+static inline void findvma_stat_inc_cachemiss(void)
+{
+	spin_lock(&findvma_stat_lock);
+	if (!findvma_stat_proc)
+		findvma_stat_init();
+	findvma_stat_cachemiss++;
+	spin_unlock(&findvma_stat_lock);
+}
+
+
+static inline void findvma_stat_inc_fail(void)
+{
+	spin_lock(&findvma_stat_lock);
+	if (unlikely(!findvma_stat_proc))
+		findvma_stat_init();
+	findvma_stat_fail++;
+	spin_unlock(&findvma_stat_lock);
+}
+
+#else /* MMAP_FINDVMA_STATS */
+# define findvma_stat_inc_cachehit()	do { } while (0)
+# define findvma_stat_inc_cachemiss()	do { } while (0)
+# define findvma_stat_inc_fail()	do { } while (0)
+#endif /* MMAP_FINDVMA_STATS */
+
 /* Look up the first VMA which satisfies  addr < vm_end,  NULL if none. */
 struct vm_area_struct * find_vma(struct mm_struct * mm, unsigned long addr)
 {
@@ -1275,10 +1399,15 @@ struct vm_area_struct * find_vma(struct 
 				} else
 					rb_node = rb_node->rb_right;
 			}
-			if (vma)
+			if (vma) {
 				mm->mmap_cache = vma;
-		}
+				findvma_stat_inc_cachemiss();
+			}
+		} else
+			findvma_stat_inc_cachehit();
 	}
+	if (!vma)
+		findvma_stat_inc_fail();
 	return vma;
 }
 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: find_vma() cachehit rate
  2004-11-21  9:54 find_vma() cachehit rate Michael Buesch
@ 2004-11-22  7:10 ` Nick Piggin
  2004-11-23 13:01   ` Marcelo Tosatti
  0 siblings, 1 reply; 3+ messages in thread
From: Nick Piggin @ 2004-11-22  7:10 UTC (permalink / raw)
  To: Michael Buesch; +Cc: Linux-MM

Michael Buesch wrote:
> Hi,
> 
> I just saw this comment in find_vma():
>   /* Check the cache first. */
>   /* (Cache hit rate is typically around 35%.) */
> 
> I just wanted to play around a bit. Just for fun.
> So I wrote the attached patch to collect find_vma()
> statistics. I was wondering why my cache hit rate is around
> 60%. It's always between 55 and 65 percent. Depending on
> the workload.
> Is this on obsolete comment from the 2.4 days, maybe?
> 
> mb@lfs:~$ cat /proc/findvma_stat 
> findvma_stat_cachehit  == 356524
> findvma_stat_cachemiss == 248728
> findvma_stat_fail      == 0
> cachehit percentage    == 58%
> cachemiss percentage   == 41%
> fail percentage        == 0%
> 
> My kernel is:
> mb@lfs:~$ uname -r
> 2.6.10-rc2-ck2-nozeroram-findvmastat
> 
> If you are interrested to comment on this, please CC: me,
> as I'm not subscribed to this mailing list. Thanks.
> 

I think the cache hit rate will be pretty variable depending on the
workload. For example, anything making use of threads, especially on
an SMP system has the potential to decrease the cache's performance.

I wouldn't worry too much about the comment - it isn't really
misleading, at worst inaccurate in a harmless sort of way. Basically
it is there to say "hey, this really does help", I guess.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: find_vma() cachehit rate
  2004-11-22  7:10 ` Nick Piggin
@ 2004-11-23 13:01   ` Marcelo Tosatti
  0 siblings, 0 replies; 3+ messages in thread
From: Marcelo Tosatti @ 2004-11-23 13:01 UTC (permalink / raw)
  To: Nick Piggin; +Cc: Michael Buesch, Linux-MM

On Mon, Nov 22, 2004 at 06:10:13PM +1100, Nick Piggin wrote:
> Michael Buesch wrote:
> >Hi,
> >
> >I just saw this comment in find_vma():
> >  /* Check the cache first. */
> >  /* (Cache hit rate is typically around 35%.) */
> >
> >I just wanted to play around a bit. Just for fun.
> >So I wrote the attached patch to collect find_vma()
> >statistics. I was wondering why my cache hit rate is around
> >60%. It's always between 55 and 65 percent. Depending on
> >the workload.
> >Is this on obsolete comment from the 2.4 days, maybe?
> >
> >mb@lfs:~$ cat /proc/findvma_stat 
> >findvma_stat_cachehit  == 356524
> >findvma_stat_cachemiss == 248728
> >findvma_stat_fail      == 0
> >cachehit percentage    == 58%
> >cachemiss percentage   == 41%
> >fail percentage        == 0%
> >
> >My kernel is:
> >mb@lfs:~$ uname -r
> >2.6.10-rc2-ck2-nozeroram-findvmastat
> >
> >If you are interrested to comment on this, please CC: me,
> >as I'm not subscribed to this mailing list. Thanks.
> >
> 
> I think the cache hit rate will be pretty variable depending on the
> workload. For example, anything making use of threads, especially on
> an SMP system has the potential to decrease the cache's performance.
> 
> I wouldn't worry too much about the comment - it isn't really
> misleading, at worst inaccurate in a harmless sort of way. Basically
> it is there to say "hey, this really does help", I guess.

BTW, would be interesting to be able to use the PMC (performance counters) 
driver from mikpe to precisely measure cache hit ratio all over the kernel.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-11-23 13:01 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-11-21  9:54 find_vma() cachehit rate Michael Buesch
2004-11-22  7:10 ` Nick Piggin
2004-11-23 13:01   ` Marcelo Tosatti

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox