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] [RFC] Transcendent Memory ("tmem"): a new approach to ph

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] Transcendent Memory ("tmem"): a new approach to physical memory management
From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Date: Thu, 8 Jan 2009 21:38:19 +0000
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 08 Jan 2009 13:38:42 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <96f92226-38e2-4a9e-94bf-0ddd3310491f@default>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903
References: <96f92226-38e2-4a9e-94bf-0ddd3310491f@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> Comments and questions welcome.  I also plan to submit an
> abstract for the upcoming Xen summit and, if accepted, give
> a talk about tmem there.

I assume you've looked at how S/390 handles this problem - the guests can
mark pages as stable or unused and the rest is up to the hypervisor ? No
complex pool interfaces and the resulting interface slots into the Linux
kernel as a pair of 1 liners in existing arch_foo hooks in the mm. The
S/390 keeps the question of shared/private memory objects separate from
the question of whether they are currently used - a point on which I
think their model and interface is probably better.

I would look at the patches but the URL you give contains nothing but an
empty repository. I'd be interested to see how the kernel patches look
and also how you implement migration of some of the users of a shared
pool object - do you implement a full clustered memory manager and what do the
performance figures look like across networks ? How do you find a pool
across the network ?

Its interesting as you can do a lot of other interesting things with this
kind of interface. Larry McVoy's bitcluster SMP proposal was built on a
similar idea using refcounted page loans to drive a multiprocessor NUMA
box as a cluster with page sharing.

Alan

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