Date: Fri, 10 Jan 2003 18:48:17 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Archie Cobbs <archie@dellroad.org> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Virtual memory question Message-ID: <20030111024817.GA2615@HAL9000.homeunix.com> In-Reply-To: <200301110200.h0B20rUC024725@arch20m.dellroad.org> References: <200301110200.h0B20rUC024725@arch20m.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Archie Cobbs <archie@dellroad.org>: > The question is: how does the performance of various FreeBSD system > calls (especially mmap() and munmap()) degrade when a process has > lots and lots of tiny regions mapped into memory? > > I'm working on a memory allocator that would allocate say a few > pages at a time, using mmap() (instead of sbrk()). So over time a > process may end up with hundreds or even thousands of short, mmap()'d > regions of memory. Is this going to cause any weird problems or > slowness? FreeBSD will combine adjacent mappings of the same type into a single object, so you shouldn't see a performance degradation in that case. I believe the vm_map entries are now laid out in a tree, so even if the map does become fragmented, performance should still be acceptable. > BTW this idea was spawned by this text in the sbrk(3) man page: > > The brk() and sbrk() functions are legacy interfaces from > before the advent of modern virtual memory management. > > Along those lines, why does our malloc(3) library use sbrk(3) instead > of mmap(), which would enable returning free pages back to the system > more readily (since the pages would not have to be contiguous)? malloc(3) returns pages to the system using madvise(2) (but only if the appropriate option is enabled). This fragments the map anyway, so I don't know why sbrk(3) is used. Perhaps sbrk() winds up having slightly lower overhead. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030111024817.GA2615>