From owner-freebsd-arch Fri Jan 10 18:48:22 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 731F537B401 for ; Fri, 10 Jan 2003 18:48:21 -0800 (PST) Received: from HAL9000.homeunix.com (12-233-57-224.client.attbi.com [12.233.57.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBE8A43F1E for ; Fri, 10 Jan 2003 18:48:20 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id h0B2mHIZ002750; Fri, 10 Jan 2003 18:48:17 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id h0B2mHRx002749; Fri, 10 Jan 2003 18:48:17 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Fri, 10 Jan 2003 18:48:17 -0800 From: David Schultz To: Archie Cobbs Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Virtual memory question Message-ID: <20030111024817.GA2615@HAL9000.homeunix.com> Mail-Followup-To: Archie Cobbs , freebsd-arch@FreeBSD.ORG References: <200301110200.h0B20rUC024725@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301110200.h0B20rUC024725@arch20m.dellroad.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Archie Cobbs : > 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