Date: Fri, 10 Jan 2003 18:00:53 -0800 (PST) From: Archie Cobbs <archie@dellroad.org> To: freebsd-arch@freebsd.org Subject: Virtual memory question Message-ID: <200301110200.h0B20rUC024725@arch20m.dellroad.org>
next in thread | raw e-mail | index | archive | help
Dear freebsd-arch,
Hope it's OK to ask a simple question here, it wasn't clear where
else would be the right place to ask.
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?
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)?
Thanks,
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
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?200301110200.h0B20rUC024725>