Looks to me like the VM code is slowly growing a linked list
somewhere, when given repeated mmap()/munmap() calls for small
regions.



Jukka Marin writes:

 >On Tue, Jul 15, 1997 at 10:35:32AM +0300, Jukka Marin wrote:
 >> The three munmap() calls take over 20 ms!  Why?  It seems that these calls
 >> are slowing down grtadually.  During the last ktrace of the X server, they
 >> were taking about 2 ms each.
 >
 >Getting even worse:
 >
 >   203 XF86_SVGA 0.000187 CALL  mmap(0,0x27000,0x3,0x1002,0xffffffff,0,0,0)
 >   203 XF86_SVGA 0.000143 RET   mmap 286797824/0x11183000
 >   203 XF86_SVGA 0.009413 CALL  munmap(0x111aa000,0x27000)
 >   203 XF86_SVGA 0.000227 RET   munmap 0
 >   203 XF86_SVGA 0.000057 CALL  mmap(0,0x27000,0x3,0x1002,0xffffffff,0,0,0)
 >   203 XF86_SVGA 0.000130 RET   mmap 286957568/0x111aa000
 >   203 XF86_SVGA 0.009094 CALL  munmap(0x11117000,0x27000)
 >   203 XF86_SVGA 0.000229 RET   munmap 0
 >   203 XF86_SVGA 0.000059 CALL  mmap(0,0x27000,0x3,0x1002,0xffffffff,0,0,0)
 >   203 XF86_SVGA 0.000132 RET   mmap 286355456/0x11117000 
 >   203 XF86_SVGA 0.009397 CALL  munmap(0x1113e000,0x27000)
 >   203 XF86_SVGA 0.000224 RET   munmap 0
 >
 >Almost 30 ms is spent in the munmap() calls now.


I havent' UTSLed or anything but this _really_ looks as if there's a
linked-list or other O(n) structure inside the kernel that's
accumulating overhead as time goes on.

Linux uses an AVL tree to keep track of the popuulated portions of a
process's address space.  mmap()ing and un-mmap()ing lots of tiny
regions works okay there.

Your data suggests that on NetBSD, this runs into a performance bug.
It looks to me like you're gettin a different chunk of address space
each time, which is also consistent with a slowly-growing linked list.
(Where else would the state be kept?)