From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@9fans.net
Subject: mmap
From: "Russ Cox" <rsc@swtch.com>
Date: Thu, 17 Jul 2008 10:24:20 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20080717142135.539A31E8C1C@holo.morphisms.net>
Topicbox-Message-UUID: ea9acd4e-ead3-11e9-9d60-3106f5b1d025

Mmap means many things to many people.

Using mmap is most often not a matter of
performance as much as it is a matter of
flexibility: being able to mmap files is about
as close as most operating systems get to
exposing the underlying page table hardware,
which lets applications that aren't happy with
the OS-provided interface essentially design
their own.  The canonical example is databases,
which would really prefer to be operating systems
except for the whole having to write hardware
drivers thing.  9vx is another example.

If all you want is to map a few read-only (or at least
non-write-back) files, like you'd need to implement
dynamically-loaded shared libraries, that's not too hard
to add.  Back when I did the first cut of linuxemu,
I changed segattach to accept 'file!a.out' as a segment name.
If you've got a lot of these, you might need to
change the segment array to be larger or perhaps
dynamically sized.  The particular interface I chose
felt clumsy so I never even suggested putting it into
the kernel, but mostly you can reuse the code that
demand-loads ordinary Plan 9 binaries.

The shared-library kind of mmap is by far the simplest
mmap use case.  Even allowing mmap as a surrogate
for malloc would probably push you pretty far toward
needing to rewrite the memory system, since the
mmap-based mallocs tend to use a large number of
small mappings.

True mmap support in the Plan 9 kernel would
require rewriting the entire memory system to
work in terms of pages instead of the coarser
regions the kernel calls segments (text, data, bss,
stack).  This would be a lot of work with almost
zero benefit.  I'd rather let those applications not
happy with what Plan 9 provides just not use Plan 9.
There's no need to be all things to all people.

Also, on Plan 9, shared memory means that the
memory at the time of rfork is shared.  If one proc
then does a segattach, the other proc sharing its
memory will not see the segattach.  The same is
true of segdetach.  This is another reason that you
can't just reuse the existing mechanisms to hack
in a traditional full-featured mmap.  To really get
those right you might need (gasp) TLB shootdowns,
which would be even more work.

It's nice that Plan 9's memory system is simple--just
a few segments, each of which is a run of pages.
"True" mmap support would destroy that.  Please don't.

Russ