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

To: Rik van Riel <riel@xxxxxxxxxx>
Subject: Re: [Xen-devel] copy on write memory
From: Peri Hankey <mpah@xxxxxxxxxxxxxx>
Date: Tue, 16 Nov 2004 09:44:49 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 16 Nov 2004 11:11:50 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: <Pine.LNX.4.61.0411151934140.20252@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <41992736.8040504@xxxxxxxxxxxxxx> <Pine.LNX.4.61.0411151934140.20252@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
Certainly, UML is best known for copy on write filesystems. But UML's SKAS mode is a different way of managing memory, and that was the starting point for this proposal, which is about using the copy on write semantics of Linux memory management to share memory pages between Xen domains. I see now that one person's starting point may prove to be another's red herring.

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).

In the standard case of a single OS on a single machine, all processes are loaded from a common filesystem, so the OS knows which page sets start out with shared information. It can use this information to share pages between processes so long as those pages are not written to, allocating distinct pages to distinct processes when those pages are written to - the copy on write semantics.

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.

In effect we create a memory manager privilege. Suppose we have a memory manager domain M1 with a collection of memory client domains M1-x, where each memory client domain has its own kernel address space KASx, a set of modified pages Wx and a set of shared pages Rx. Then the situation we want to see is this:

M1      doesn't actually execute any application code, just manages memory for 
its clients
M1-a    executes application code in (KASa, Ra, Wa) calling on M1 for memory 
M1-b    executes application code in (KASb, Rb, Wb) calling on M1 for memory 
M1-c    executes application code in (KASc, Rc, Wc) calling on M1 for memory 

There is a connection with copy-on-write storage. The execution state of a client domain x can be frozen as:

'Rx'  which identifies a set of pages that are shared read-only with similar 
KASx  which is the kernel address space page set for this domain
Wx    which is the set of user address space pages that have been written to by 
this domain

The total long-term state of a client domain can be characterised by adding

'SRx' which identifies blocks in read-only storage that are shared with similar 
SWx   which identifies which files in read-write storage that belong to this 
client domain.

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.


On Mon, 15 Nov 2004, Peri Hankey wrote:

It occurred to me that the equivalent in the Xen world would be to use one Linux xenU domain purely as a page-table manager for a collection of separate xenU domains that are expected or known have similar process populations.

UML copy on write is only for filesystems, isn't it ?

The Xen equivalent would be cloning the xenU root filesystem
as an LVM snapshot, from a read-only LVM snapshot.  Then each
xenU virtual system would only use the disk space it writes
to and no more.

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