> if that doesn't compel you, running upas imap server for ~40 users
> with 1.3gb of inboxes might. since upas has the bad manners to load
> the entire mailbox, we're using about 90% of the 3.5gb bios will spare
> us in 32bit mode. i also watched it at 100% cpu for a solid hour
> yesterday.

There is supposedly an amd64 port somewhere which should let you use
more ram, but you already know that. Of course we all also know how
releasing code that people might find useful and even improve is a
crazy idea...

> it's embarassing that mail is such a hog. this is our scalability plan:
>
> /n/sources/contrib/quanstro/src/nupas/

Agreed

uriel

Uriel wrote:
> On Wed, Jul 16, 2008 at 5:02 PM, Benjamin Huntsman
> wrote:
>
>>> i can't agree with this label "research os" if you mean
>>> to imply that it's not stable or somehow unfinished.
>>>
>> Not at all. Just meant that one doesn't run their company's Oracle database on it.
>> Not because it's not worthy of doing so, but such things just aren't compiled for it.
>>
>
> You might be able to run Oracle with linuxemu...
Hmmm... I would doubt it until tried... I could imagine that databases
use mmap() havily
and the mmap() of linuxemu is just a hack that that reads the whole
file-mapping in... and writes
the whole thing out again on msync()... thats one reason the startup
time of firefox is so
slow on linuxemu (besides it makes millions of stats/open/access calls
when starting up)
> if Firefox runs, anything can!
>
I have seen so mutch programs breaking in obscure ways while hacking
linuxemu... sure,
sometimes you are lucky and it just works... but still dont expect too
mutch...
> uriel
>
cinap

> I could imagine that databases use mmap() havily

it's a little mystery for me why they would do that since it's slower (or ought to be),
because the trap path and fault recovery must do more work than syscall (perhaps much more).
it's also difficult then to optimise the replacement strategy for the application
without madvise calls (and you trust those implicitly?) but those are system calls that cost time.

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 (or ought to be),
> because the trap path and fault recovery must do more work than syscall (perhaps much more).
> it's also difficult then to optimise the replacement strategy for the application
> without madvise calls (and you trust those implicitly?) but those are system calls that cost time.
>
>
makes sense of course...

but at least mysql uses mmap() for some table types as a caching mechanism.
http://www.mysqlperformanceblog.com/...ap-feature-51/

this may just be an exception and real databases use read()/write() syscalls
and implement the caching themself.

but where should i know... i dont need/use databases and have not looked
at the sourcecode of one.

cinap

On Thu, 2008-07-17 at 10:07 +0100, 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 (or ought to be),

slower compared to what? I'd expect the biggest slowdown for
read()/write() be not the price of a syscall, but what you
pay for copying data in/out of the kernel. With mmap() there's
no copying.

Thanks,
Roman.

On Thu, Jul 17, 2008 at 05:55:00AM -0700, ron minnich wrote:
> 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?

I think Russ has given this as an exercise to more than
one member of the list in the past :-)

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

On Thu, Jul 17, 2008 at 6:45 AM, erik quanstrom wrote:

> i haven't found this to be the case.

it's not always 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.

A very bad mistake for streaming data.


> 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?
>

In certain cases, the OS memory management for pages can be exploited
and it can do a good job for you. Not in all cases of course.

ron

Paweł Lasek wrote:
> A much more important reason might be the fact that memory mapping of
> files is only one function of mmap() and company. Basically when you
> have mmap() and munmap() you can write your own allocator (which might
> be very useful, especially for databases). I won't delve into using it
> for I/O, but a specialized memory allocator can get you a big speedup
> - after all application developer knows the memory usage pattern of
> his app better than kernel/system library.
>
you can write you own allocator with brk() or
segattach()/segbrk()/segfree() too... the
only things you cant is:

- map on some fixed address
- remap

cinap

> 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

On Thu, 2008-07-17 at 05:55 -0700, ron minnich wrote:
> 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?

I've commented privately to Erik that this is, in fact, what I'm
interested in: using mmap() not as a first-class abstraction,
but as a useful optimization technique in places where it can
speed things up.

Thanks,
Roman.

P.S. Of course, as was pointed out
(a) speeding things up in one place (read/write) could easily
slow them down elsewhere in the kernel
(b) there's no point in lots of RPMs if 99% you're in neutral
and (a) is precisely why I tend to ask question instead
of implementing this stuff up -- I'm just not all that much
of an OS kernel guy to be 100% sure that it will end up
being worth it.