From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <af5b723f0bbfdcecd719dbf0fb2cd8e8@quanstro.net>
To: 9fans@9fans.net
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu, 17 Jul 2008 09:45:43 -0400
In-Reply-To: <13426df10807170555s746fa829p130970922058f692@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] 8 cores
Topicbox-Message-UUID: ea7958f8-ead3-11e9-9d60-3106f5b1d025

> 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).

i haven't found this to be the case.

in a former life, one i'd rather forget, i did
full text search.

in order to return the full text, we had to go
get the document.  due to the very crappy
nature of ext2, it was not feasable to store
the documents individually.  they had to
be bundled up in chunks of about 1gb.

being young and easily distracted by shiny
bits, i decided to use mmap.  to my shock
and horror, this turned out to be really slow.
so then i modified the mmap to only map
part of the file.  this was faster, but the
speed of this operation was strongly influenced
by the size of the file.

if i had been even moderately smart, i would
have just read the part of the file i needed.
it would have been much, much faster.

as to using mmap for memory management,
that confuses me.  it's like saying the os should
provide linked lists, because developers can't do
it.  isn't part of the argument here that applications
know better how to manage buffers?

personally, i suspect the reason the unix guys
need mmap, is to support 100mb of shared libraries
for firefox.

if you want mmap, why not start over with
something like multics.  then you can get
rid of the annoying file abstraction all together.

(of course, disagreeing with ken can be a
dangerous business.)

- erik