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] Seamlessly sharing identical memory pages among domains

To: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Seamlessly sharing identical memory pages among domains
From: Kip Macy <kmacy@xxxxxxxxxxx>
Date: Fri, 21 May 2004 04:21:42 -0700 (PDT)
Cc: "Scheer, Roque" <roque.scheer@xxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 21 May 2004 12:25:53 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: <E1BR3xI-0000g9-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: <E1BR3xI-0000g9-00@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
>
> Yep. The only slight subtlety is that that the page in question
> may appear in multiple page tables and at multiple VAs: if the
> page is truly read-write shared in the guest (e.g. sysv shared
> memory [*]) then it it will be necessary to find all the ptes and
> patch them to the newly allocated machine frame. I think such
> pages are rare, and tracking them down by scanning the list of
> vma's that are mapping the object (e.g. a file) in question is
> pretty easy and quick. However, this would most sensibly be done
> by making minor modifications to architecture independent code,

Just adding an upcall wouldn't be too terrible. Iterating through the
list of vtop mappings for a page should be fairly light weight.
Politically, the most realistic thing to do is put the arch-independent
code changes in the xen arch-dependent tree wherever possible. I don't
think anyone wants to see xen specific changes going on outside of the
arch subtree.

> [*] Hmm, do memory mapped files behave like this too? I can't
> remember.

If multiple processes share the page read-write, the OS has to have some
way to know about it.



                                -Kip


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel