WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] CoW memory and Parallax questions.

To: d515a@xxxxxxxxx
Subject: Re: [Xen-devel] CoW memory and Parallax questions.
From: Kip Macy <kip.macy@xxxxxxxxx>
Date: Tue, 4 Oct 2005 10:34:37 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Jacob Gorm Hansen <jacobg@xxxxxxx>
Delivery-date: Tue, 04 Oct 2005 17:32:11 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Ovvn853RCJhbho/fgPel89flcokN6OSm2zKyclrozbaL9xHcWI7sHepzB6gnBMcMXcr3pfVpnO6FpsvswPXDJ79cbVQbINxlf1Vu1tsVloy4hOdryagk7GguMKPaLryUVLtQKa2z/eT59UljOGp7W6UE3ty3wyFZMD9xMZWLk74=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1128426352.5242.45.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <Pine.LNX.4.61.0509300549450.23433@xxxxxxxxxxxxxxxxxx> <1128356411.6304.32.camel@xxxxxxxxxxxxxxxxxxxxx> <b1fa29170510031212x1609935etaa812e8d8481673d@xxxxxxxxxxxxxx> <e08041f30510040153v7071b6d4u5251e1a991c28f5f@xxxxxxxxxxxxxx> <1128426352.5242.45.camel@xxxxxxxxxxxxxxxxxxxxx>
Reply-to: Kip Macy <kip.macy@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I don't think HV level privilege is necessary. Take a look at the mergemem work. A service running in the background in DOM0 is a potentially viable approach.
 
     -Kip


On 10/4/05, Jacob Faber Kloster <jk@xxxxxxxxx> wrote:
That certainly sounds like an interesting approach. Our immediate
approach was something along the lines of making a separate service, on
the hypervisor level of privilege, with complete overview and control of
the memory. Doing the content based sharing scheme will, as you also
noted, open up the possibility of overcommitment of memory. Some kind of
scheduling will be needed to handle this. One solution could be to
suspend a VM to disk or introduce a swapping..

But at this point in time we are not focusing on any specific solution,
we are just investigating whether it is possible and feasible to share
memory.

Best regards
Jacob Faber Kloster (group email d515a@xxxxxxxxx)


On Tue, 2005-10-04 at 10:53 +0200, Jacob Gorm Hansen wrote:
> My take on that would be to introduce read-only pages and a context
> index (tree or hashtable) in Xen, and then handle the CoW part in the
> guest OSes. That removes the need for any policy on how to handle
> overcommits in Xen or Dom0, in the case where all domUs decide to fill
> up their pages with random data.
>
> Jacob


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel