[lkml]   [2001]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[PATCH] mm/mmap.c find_vma(), kernel 2.4.0

I was looking through some of the memory management code today and
came across something that may provide a minor performance boost. I have
included a patch below for the 2.4.0 source.

In the find_vma function a cached vma is checked and if that is
not the requested vma, the linked list (unless there's an avl tree) is
traversed from the beginning. My thought was that if the cached vma is
somewhere in the middle of a "long" list, and the memory address we are
looking for is past the vm_end of the cached vma, well, the traversal can
just start at the next vma after the one that was cached.

I put in some code to count the number of times my change took the
vma after the cached one and the number of times it went the other way.
Through these simple counts I determined that the requested vma was after
the cached one about 46% of the time.

Anyway, this is a simple patch and may not make that much of a
difference in performance but hey, this is my first time submitting a
patch and I decided to start small. I would be interested in hearing any
feedback from the mm gurus out there.

| Robert Wienholt, Jr. | Legion Technologies, LLC |
| Lead Programmer | 8910 Whitetail Ct. |
| | Perry Hall, MD 21128 |

--- linux-2.4.0/mm/mmap.c Sat Dec 30 12:35:19 2000
+++ linux/mm/mmap.c Sun Jan 7 20:35:59 2001
@@ -413,7 +413,20 @@
if (!(vma && vma->vm_end > addr && vma->vm_start <= addr))
if (!mm->mmap_avl) {
/* Go through the linear list. */
- vma = mm->mmap;
+ /*
+ If we missed the cache, check to see if the memory area
+ would be after the cached one and start the list walk
+ from there.
+ RGW -- 01/07/2001
+ */
+ if (vma && vma->vm_end <= addr)
+ vma = vma->vm_next;
+ else
+ vma = mm->mmap;
while (vma && vma->vm_end <= addr)
vma = vma->vm_next;
} else {

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:52    [W:0.032 / U:2.892 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site