From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jacob Faber Kloster Subject: Re: CoW memory and Parallax questions. Date: Tue, 04 Oct 2005 13:45:52 +0200 Message-ID: <1128426352.5242.45.camel@localhost.localdomain> References: <1128356411.6304.32.camel@localhost.localdomain> Reply-To: d515a@cs.aau.dk Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jacob Gorm Hansen Cc: Kip Macy , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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@cs.aau.dk) 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