Date: Sat, 11 Jan 2003 14:44:44 -0800 From: Peter Wemm <peter@wemm.org> To: "Alan L. Cox" <alc@imimic.com> Cc: arch@freebsd.org Subject: Re: Virtual memory question Message-ID: <20030111224444.94D102A89E@canning.wemm.org> In-Reply-To: <3E209AA5.ED387618@imimic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030111224444.94D102A89E>