On Wed, Jul 30, 2008 at 18:36, Roman V. Shaposhnik <[EMAIL PROTECTED]> wrote: > As Russ, quite rightfully, pointed out: mmap() means different things > to different people. The tragic part is, that it tries to do lots of > things but it doesn't do anything particularly well. Personally, my > experience of trying to use mmap() as a useful abstraction for the > CPU's MMU was the last straw. It can't do even that reliably > and in a portable fashion. Not to digress, but I was even more surprised > to learn that there's not a single API on UNIX that can: > http://thread.gmane.org/gmane.os.netbsd.devel.kernel/6392/focus=6457 > > So, what mmap() (the way it is done on UNIX) is good for? Here's my > personal list. Feel free to add (and suggest alternatives on systems > lacking mmap() such as Plan9): > * a *lazy* way of handling highly irregular I/O over large files. > Cases, where you can't really tell which parts of the file are > going to be needed. The best example here is mmap() on exec. > You don't have to read() all of .text if the actual execution path > only takes you to a couple of routines. > * an optimization for regular I/O. To some extent, I've always > wondered why read always takes its second argument -- a lot of > times I don't really care where the buffer with the data I need > ends up in my address space. > > That's pretty much it. Everything else, feels like a hack in a dire > need of a better abstraction.
SBCL uses it to kick out system vm out of managing it's memory. At least the version I got on linux calls mmap() with MAP_ANONYMOUS, rwx permissions and I think MAP_FIXED. Unfortunately, when you disable overcommit it fails to start on my machine, because I clearly don't have 8GB of free memory&swap for it (I total at 2.5 GB w/ swap). I wish someone gave a plain interface to just took control of memory space... I also had seen a simple malloc() implementation (targeted at people who want to write their own systems) that had a simple form of mmap/unmap calls (without mapping of files) as it's only requirement. If it's the only kernel-exported API for managing memory, it can make sense. I think that was done in L4 API, which organizes it's processes by address spaces (the distinction between what we call a process and thread being only their address spaces - a process was a set of threads grouped by address space). A process could also implement it's own pager and create processes that used it's address space (basically what 9vx does, as you could also install appropriate syscall trampolines). As a counter-example, MS Windows' Notepad.exe is one of the worst offenders when it comes to mmap(). To put it simply, the reason it doesn't work on large files is that it mmaps them. ALWAYS. It's even stated in IFS SDK, that "implementation of memory mapping mechanism is required to get notepad to work on the filesystem in question". > Thanks, > Roman. > -- Paweł Lasek
