From owner-freebsd-arch Sat Jan 11 14:29: 3 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 EBC3D37B401 for ; Sat, 11 Jan 2003 14:29:01 -0800 (PST) Received: from eumenes.hosting.swbell.net (eumenes.hosting.swbell.net [216.100.98.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 336C443F13 for ; Sat, 11 Jan 2003 14:29:01 -0800 (PST) (envelope-from alc@imimic.com) Received: from imimic.com (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) by eumenes.hosting.swbell.net id RAA06417; Sat, 11 Jan 2003 17:28:54 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <3E209AA5.ED387618@imimic.com> Date: Sat, 11 Jan 2003 16:28:53 -0600 From: "Alan L. Cox" Organization: iMimic Networking, Inc. X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: arch@freebsd.org Subject: Re: Virtual memory question Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit 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 >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? 5.x is much, much better at handling this than 4.x. That said, it's time for a list of disclaimers. 1. Lookups are accelerated in 5.x, but finding the right amount of free virtual address space isn't. The free space hint often works well, but can fail miserably. 2. Coalescing of mappings is complicated. The program that was posted here is a little too simplistic in its "workload". Specifically, it never touches any of the memory and never munmaps any of the memory. If it did both, you would see fragmentation in the vm_map and situations where you would say, "Gosh, why aren't these adjacent map entries coalesced?" The reason is that distinct anonymous memory objects got allocated. Currently, the only "work-around" is not to use anonymous memory. Create a "heap" file, use MAP_NOSYNC for performance, and make sure that you pass the right file offset to mmap(). Regards, Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message