From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <13426df10807170555s746fa829p130970922058f692@mail.gmail.com> Date: Thu, 17 Jul 2008 05:55:00 -0700 From: "ron minnich" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: <2125ed224c77c85fc13d81eb95377a2a@terzarima.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <487EFBC8.4060607@gmx.de> <2125ed224c77c85fc13d81eb95377a2a@terzarima.net> Subject: Re: [9fans] 8 cores Topicbox-Message-UUID: e9cd9ff4-ead3-11e9-9d60-3106f5b1d025 On Thu, Jul 17, 2008 at 2:07 AM, Charles Forsyth wrote: >> I could imagine that databases use mmap() havily > > it's a little mystery for me why they would do that since it's slower Well, depends. Non-mmap you have to do the storage management in the app. mmap, you're using the storage management in the kernel to figure out where the data goes, as well as all the LRU stuff to figure out what happens when you're running out of memory and you need to get rid of some of it.. Most kernels do a better job than most people at this sort of thing (at least from code I've seen). mmap can also reduce memory pressure, since there's only one copy of the data (for some kernels anyway; others are smarter). In a number of kernels, the read path for page-aligned page-sized data is via mmap anyway, so any measurement at that point is going to make mmap look cheaper. Even the read path is an mmap! Looking at the Plan 9 exec path it's hard to see a reason that Plan 9 could not do mmap, it just doesn't. But lots of code nowadays depends on mmap being there. Is there something I'm missing? ron