All of lore.kernel.org
 help / color / mirror / Atom feed
From: mike@mikebell.org
To: xen-devel@lists.sourceforge.net
Subject: Feasability of a shared memory mapping filesystem
Date: Mon, 23 Feb 2004 04:38:13 -0800	[thread overview]
Message-ID: <20040223123812.GD540@tinyvaio.nome.ca> (raw)

I'm curious about the feasability of a filesystem that makes memory maps
shared across domains. The reason for this is that, unless I'm mistaken,
it would mean that executables and shared libraries would share memory
across domains.

As I understand it, the file and its shared libraries are mapped into
virtual memory and (assuming no relocations are needed) those pages just
sit there as read only mmaps until needed, at which point pages of real
RAM are loaded with their contents. What I'm wondering is whether or not
those pages of real RAM could be shared across virtual domains using a
special filesystem, so that for those with a shared read-only /usr all
the xen domains would use the same pool of real RAM for executables,
rather than each one having their own private RAM pages with identical 
copies of libc.

With RAM so cheap these days, this may seem like a minor issue on xen
where the number of domains is comparitivly limited, but OTOH xen on x86
will most likely only ever support 4G of RAM now that both Intel and
AMD are moving to 64 bit chips, so there would seem to be some potential
use.

Whether it's a read-only only filesystem or it works also for shared
writable mmaps is pretty much optional in my view, though interdomain
shared memory might be useful for some people (like web applications
where you don't want to use SQL or another networked database).

So, is this possible? If so, how difficult are we talking? Does xen have
a mechanism for sharing a page of memory between multiple domains, and
if so would there be any additional support required from xen or would
it just be a matter of implementing the xenolinux filesystem?


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

             reply	other threads:[~2004-02-23 12:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-23 12:38 mike [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-02-23 13:20 Feasability of a shared memory mapping filesystem xen
2004-02-23 14:46 ` Ian Pratt

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=20040223123812.GD540@tinyvaio.nome.ca \
    --to=mike@mikebell.org \
    --cc=xen-devel@lists.sourceforge.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.