9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] mmap
@ 2008-11-03  0:50 erik quanstrom
  2008-11-03  1:36 ` ron minnich
  0 siblings, 1 reply; 51+ messages in thread
From: erik quanstrom @ 2008-11-03  0:50 UTC (permalink / raw)
  To: weigelt, 9fans

> * Roman V. Shaposhnik <rvs@sun.com> wrote:
> > On Wed, 2008-07-30 at 17:29 +0200, Enrico Weigelt wrote:
> > > Convenience is one point (sometimes be a big point), but another
> > > important one is sharing. Without mmap(), an (real) shared library
> > > support most likely will require special kernel support.
> >
> > What aspect of shared libraries are you aching for? Dynamic
> > linking or the dynamic loading?
>
> 3rd: Sharing pages.

segment(3) already provides this.

- erik



^ permalink raw reply	[flat|nested] 51+ messages in thread
* mmap
@ 2008-07-17 14:24 Russ Cox
  2008-07-17 14:34 ` [9fans] mmap erik quanstrom
  2008-07-29  8:52 ` Enrico Weigelt
  0 siblings, 2 replies; 51+ messages in thread
From: Russ Cox @ 2008-07-17 14:24 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 51+ messages in thread

end of thread, other threads:[~2008-11-10 23:15 UTC | newest]

Thread overview: 51+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <1d371286c515cad580f68eddbe2cdf57@quanstro.net>
2008-11-03  3:18 ` [9fans] mmap Enrico Weigelt
2008-11-03  3:31   ` ron minnich
2008-11-03  6:27     ` Charles Forsyth
2008-11-03 13:16       ` [9fans] mmap and shared libraries dave.l
2008-11-03 15:55         ` Kernel Panic
2008-11-04  1:23         ` Lyndon Nerenberg
2008-11-04  3:46         ` michael block
2008-11-05  5:17         ` Roman Shaposhnik
2008-11-05  5:21           ` ron minnich
2008-11-05  5:25             ` Lyndon Nerenberg
2008-11-03  0:50 [9fans] mmap erik quanstrom
2008-11-03  1:36 ` ron minnich
2008-11-03  6:29   ` Charles Forsyth
2008-11-03  6:58     ` ron minnich
2008-11-03  7:50       ` Bruce Ellis
2008-11-04  4:43       ` Enrico Weigelt
2008-11-04  7:15         ` Andrew Simmons
2008-11-04  8:01           ` Bakul Shah
2008-11-04 14:13             ` Charles Forsyth
2008-11-10 23:15               ` gas
2008-11-04 16:02           ` ron minnich
2008-11-04 18:19             ` Kim Shrier
2008-11-04 16:09         ` David Leimbach
  -- strict thread matches above, loose matches on Subject: below --
2008-07-17 14:24 mmap Russ Cox
2008-07-17 14:34 ` [9fans] mmap erik quanstrom
2008-07-29  8:52 ` Enrico Weigelt
2008-07-29  9:45   ` Charles Forsyth
2008-07-29 15:04   ` Alexander Sychev
2008-07-29 15:19     ` erik quanstrom
2008-07-29 15:35       ` ron minnich
2008-07-29 15:46         ` Roman V. Shaposhnik
2008-07-29 15:35     ` David Leimbach
2008-07-29 16:28   ` Venkatesh Srinivas
2008-07-29 16:55     ` Charles Forsyth
2008-07-29 17:08       ` Charles Forsyth
2008-07-30 16:36     ` Roman V. Shaposhnik
2008-07-30 17:02       ` Paul Lalonde
2008-07-31 21:39         ` Charles Forsyth
2008-07-31 23:19           ` Bakul Shah
2008-08-01  0:32             ` ron minnich
2008-08-01  3:18               ` David Leimbach
2008-08-02 13:22               ` Richard Miller
2008-08-02 16:10                 ` ron minnich
2008-08-02 19:12                   ` Richard Miller
2008-07-31  8:51       ` Paweł Lasek
     [not found]   ` <20080729162639.GA31092@satori.no-ip.org>
2008-07-30 15:29     ` Enrico Weigelt
2008-07-30 15:43       ` Roman V. Shaposhnik
2008-11-03  0:22         ` Enrico Weigelt
2008-07-30 16:25       ` Joel C. Salomon
2008-07-30 17:28         ` Kernel Panic
2008-07-30 18:26           ` erik quanstrom
2008-07-31  1:42         ` Joel C. Salomon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).