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] Copy-on-write memory to allow many more xenU domains per

To: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Copy-on-write memory to allow many more xenU domains per machine
From: urmk@xxxxxxxxxxxxxxxxx
Date: Tue, 2 Nov 2004 16:50:54 -0500
Cc: Xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 02 Nov 2004 22:00:22 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: <E1CP6Gz-0008CU-00@xxxxxxxxxxxxxxxxx>
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: <4187F44E.303@xxxxxxxx> <E1CP6Gz-0008CU-00@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4i
Check the s/390 port of the kernel for the XIP2 filesystem.  It exploits
the z/VM shared memory system to make a read-only ext2 like filesystem
that is shared amonst all the guests - and uses execute-in-place.  Any
binaries on the xip2 filesystem aren't cached into local shared memory,
they're just mapped across.

This lets an admin build explicit shared systems, does shared ro-memory
nicely, etc.  Might be worth looking into implementing similar in Xen.

Apologies if this was already discussed/noticed,

-m

On Tue, Nov 02, 2004 at 09:33:00PM +0000, Ian Pratt wrote:
>  
> > What about having a special variant of the pte-update operation, which 
> > takes as input a pointer to a pte-entry, and will change that entry into 
> > a read-only mapping of the same page contents, though perhaps with a 
> > different frame number in the pte.
> 
> I'm still not convinced we wouldn't get most of the benefit by
> just sharing pages read from the block/file system, and hence
> avoiding all the hashing. 
> 
> Collecting this data is actually very easy -- its just a case of
> coming up with a few "realistic usage scenarios" in which to
> collect the data. We'd be happy to work with someone to do
> this...
> 
> Ian
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/xen-devel


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel

<Prev in Thread] Current Thread [Next in Thread>