9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Roman V. Shaposhnik" <rvs@sun.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] mmap
Date: Wed, 30 Jul 2008 09:36:13 -0700	[thread overview]
Message-ID: <1217435773.5036.129.camel@goose.sun.com> (raw)
In-Reply-To: <20080729162834.GC31092@satori.no-ip.org>

On Tue, 2008-07-29 at 12:28 -0400, Venkatesh Srinivas wrote:
> As far as interfaces go, mmap() is pretty tragic - the underlying
> translation structures can express more interesting things, some of
> which are even worth doing.

I can't agree more. The way I look at it is that mmap() seems to
be the answer but nobody ever bothered to ask the question it is
supposed to answer.

> In a system like Plan 9, where your file servers are on the other side
> of a 9P link, this mmap thing seems dubious. If what you want is the
> convenience that you get from having all the bytes in memory, reading
> them all in wouldn't be too hard. mmap()s magic really arises when you
> have a page-cache-like-thing.

As Russ, quite rightfully, pointed out: mmap() means different things
to different people. The tragic part is, that it tries to do lots of
things but it doesn't do anything particularly well. Personally, my
experience of trying to use mmap() as a useful abstraction for the
CPU's MMU was the last straw. It can't do even that reliably
and in a portable fashion. Not to digress, but I was even more surprised
to learn that there's not a single API on UNIX that can:
    http://thread.gmane.org/gmane.os.netbsd.devel.kernel/6392/focus=6457

So, what mmap() (the way it is done on UNIX) is good for? Here's my
personal list. Feel free to add (and suggest alternatives on systems
lacking mmap() such as Plan9):
   * a *lazy* way of handling highly irregular I/O over large files.
     Cases, where you can't really tell which parts of the file are
     going to be needed. The best example here is mmap() on exec.
     You don't have to read() all of .text if the actual execution path
     only takes you to a couple of routines.
   * an optimization for regular I/O. To some extent, I've always
     wondered why read always takes its second argument -- a lot of
     times I don't really care where the buffer with the data I need
     ends up in my address space.

That's pretty much it. Everything else, feels like a hack in a dire
need of a better abstraction.

Thanks,
Roman.




  parent reply	other threads:[~2008-07-30 16:36 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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
2008-11-03  0:50 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
     [not found] <1d371286c515cad580f68eddbe2cdf57@quanstro.net>
2008-11-03  3:18 ` Enrico Weigelt
2008-11-03  3:31   ` ron minnich
2008-11-03  6:27     ` Charles Forsyth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1217435773.5036.129.camel@goose.sun.com \
    --to=rvs@sun.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).