This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] copy on write memory

> The notion is that there are applications of Xen where there would be 
> very many virtual computers running the same set of applications for 
> much of the time (eg standard web hosting, honeypots).
> * snip *
> In the Xen case, you don't want to reinvent and reimplement existing 
> mechanisms, especially as these may differ in subtle ways from one guest 
> operating system to another. So I suggest it would make sense to create 
> mechanisms that allow some Xen domains to operate as memory management 
> servers to groups of related domains.
> *snip*
> It seems to me that a memory manager domain, which pretty much has to 
> serve pages initially drawn from a filesystem that is shared read-only 
> between its clients, is also in a position to manage copy-on-write use 
> of that file system for its clients, as it already knows which blocks 
> and clean and which are dirty.

I'd thought I'd sent this before but it's not in the archives so I'll
send it again...  If this made it to the list once already, my 

On the s/390 platform, we have a new filesystem called XIP2.  This is a 
shared-memory filesystem based on ext2, which can be shared among any
number of guests.  Basically you populate the XIP2 fs and then "freeze"
it and share it.

Thats all pretty standard, but here comes the magic:  Any data in the 
XIP2 filesystem is not copied into the cached memory of the guest.
XIP = eXecute In Place.  Binaries are run directly from the shared
memory and not cached locally, so if you throw common services and 
libraries (like apache, JVM, etc from your example) into it you get the
binaries themselves shared with basically no cost to the guests.

Not to say an automatic memory manager to determine when it could do
COW of ram isn't a good avenue to pursue as well, but XIP is a fairly
good starting point for most situations that you'd want shared memory
like this, I think.

The XIP2 source code is in the IBM patches to the kernel:

and by this point it's quite likely already in the bitkeeper tree as
well, they've been pushing updates upstream.


This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
Xen-devel mailing list