From: "Matt Miller" <mmiller@hick.org>
To: <linux-kernel@vger.kernel.org>
Cc: <mmiller@hick.org>
Subject: RE: [PATCH] 2.6: mmap complement, fdmap
Date: Mon, 22 Mar 2004 13:26:01 -0600 [thread overview]
Message-ID: <PFEHKADDODPLDDIJFACJAEJHEAAA.mmiller@hick.org> (raw)
In-Reply-To: <20040322190047.GC8366@waste.org>
> > > a) what the hell for?
> >
> > It's targetted mainly as a performance enhancer. Some of the specific
> > scenarios where it would be useful are:
> >
> > a) When one cannot afford to take the performance hit of synchronizing
> > a memory range to disk due to disk size limitations or speed
> > requirements.
> > b) Some things can benefit from the ability to interface with
> memory as a
> > file.
> >
> > The specific reason for implementing this was to allow for
> loading dynamic
> > libraries in the context of a process without having to write them to
> > disk.
>
> How about tmpfs/ramfs instead? Open a file on tmpfs and mmap it and
> you've got the same thing without any of the nasty corner cases.
Because tmpfs does not allow you to map a file descriptor to a specific
memory
range inside a process. tmpfs allows you to open a file that exists only
in memory, yes, but it does not accomplish what fdmap tries to accomplish.
fdmap allows you to access arbitrary memory ranges as if they were a file.
tmpfs allows you to access a file that happens to only exist in memory.
You do not control the address range that tmpfs/ramfs map to.
A few other benefits to fdmap include:
1. Transactional operations for MTD storage - if the only "disk"
is an MTD, then one would want to avoid writing to it too much
(assuming wear-leveling alone isn't enough). So one can commit
tons of changes, then when everything's done, "collapse" to disk.
2. tmpfs adds swap -- if you don't want it to hit disk, ever (think
crypto keys) but need to manipulate it with tools that want files.
3. ramfs isn't charged to the user process, rather, it rips available
memory away from everything. By using fdmap(), it'd be interesting
to allow a "transactional storage" for processes to exist that's
automatically beancounted.
Think of fdmap as the complement to mmap. You use mmap to map a file
descriptor to a memory range so that you can operate on it directly by
memory. You use fdmap to map a memory range to a file descriptor so that
you can access the memory as if it were a file on disk.
Matt
next prev parent reply other threads:[~2004-03-22 19:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-22 4:43 Matt Miller
2004-03-22 5:30 ` viro
2004-03-22 6:14 ` Matt Miller
2004-03-22 19:00 ` Matt Mackall
2004-03-22 19:26 ` Matt Miller [this message]
2004-03-23 0:52 ` Matt Mackall
2004-03-23 4:26 ` Matt Miller
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=PFEHKADDODPLDDIJFACJAEJHEAAA.mmiller@hick.org \
--to=mmiller@hick.org \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®