Try it without doing it - the code grows quite nasty without completely
getting rid of "insert_vm_struct()".
Which I considered, but decided that 2.4.x is not the time to do so.
> I believe the best way is to allocate always the new vma, and to hide
> the merging into the lowlevel of a new insert_vm_struct (with a special
> function ala merge_segments that we can share with mprotect like in 2.2).
Oh, and THAT is going to speed things up?
Hint: the merging actually happens at a fairly high percentage for the
common cases. We win more by walking the tree twice and avoiding the
unnecessary allocation/free.
Now, if you _really_ want to do this right, you can:
- hold the write lock on the semaphore. Nobody is going to change the
list.
- walk the table just once, remembering what the previous entry was.
NOTE! You ahve to do this _anyway_, as part of checking the "do I need
to unmap anything?" Right now we just call "do_munmap()", but done
right we would walk the tree _once_, noticing whether we need to unmap
or not, and keep track of what the previous one was.
- just expand the previous entry when you notice that it's doable.
- allocate and insert a new entry if needed.
However, this absolutely means getting rid of "insert_vm_struct()", and
moving a large portion of it into the caller.
It also means doing the same for "do_munmap()".
Try it. I'd love to see the code. I didn't want to do it myself.
And remember: optimize for _well_written applications. Not for stupid
glibc code that can be fixed.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/