From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kip Macy Subject: Re: Seamlessly sharing identical memory pages among domains Date: Fri, 21 May 2004 04:21:42 -0700 (PDT) Sender: xen-devel-admin@lists.sourceforge.net Message-ID: <20040521041039.T56068@demos.bsdclusters.com> References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Ian Pratt Cc: "Scheer, Roque" , xen-devel@lists.sourceforge.net List-Id: xen-devel@lists.xenproject.org > > 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