From owner-freebsd-arch Sat Jan 11 14:44:46 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 F050937B401 for ; Sat, 11 Jan 2003 14:44:44 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id B01CD43F18 for ; Sat, 11 Jan 2003 14:44:44 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 94D102A89E; Sat, 11 Jan 2003 14:44:44 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Alan L. Cox" Cc: arch@freebsd.org Subject: Re: Virtual memory question In-Reply-To: <3E209AA5.ED387618@imimic.com> Date: Sat, 11 Jan 2003 14:44:44 -0800 From: Peter Wemm Message-Id: <20030111224444.94D102A89E@canning.wemm.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 "Alan L. Cox" wrote: > >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(). Speaking of which, I've been thinking about some sort of non-fs persistent object handle for doing mmaps. (Note: thinking about, not actually getting around to doing :-). Imagine mmapping /dev/zero, but having a persistent object per fd that was opened. This would be to enable things like fd passing to get access to another process's store and so on. Basically a replacement for the MAP_NOSYNC files, and it would be swap backed instead of vfs backed. This would be very damn useful at work. It could be ideal for malloc too since it would be a single object with coherent ordering etc. At work, we have lots of problems with complications of having a file system attached to things that we just want to shove data into and otherwise forget about. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message