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/
Home Products Support Community News


Ownership of machine pages: Was: [Xen-devel] Essay on an important Xen d

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Ownership of machine pages: Was: [Xen-devel] Essay on an important Xen decision (long)
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Wed, 11 Jan 2006 14:49:38 -0800
Delivery-date: Wed, 11 Jan 2006 22:56:09 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcYXAUw3TcOkMPR2SrK1LS2iy/JHVw==
Thread-topic: Ownership of machine pages: Was: [Xen-devel] Essay on an important Xen decision (long)
> Date: Wed, 11 Jan 2006 15:56:43 +0800
> From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
> Subject: RE: [Xen-devel] Essay on an important Xen decision (long)
> To: "Magenheimer, Dan \(HP Labs Fort Collins\)"
>       <dan.magenheimer@xxxxxx>,       "xen-devel" 
> <xen-devel@xxxxxxxxxxxxxxxxxxx>,
>       <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
> Hi, Dan,
>       Good background for discussion.

For some reason, I only got this through xen-devel (which I
only receive in digest form) so I couldn't respond directly.
But this subtopic -- though highly related -- might deserve
a new thread anyway.

> I don't think it's a good design choice by complete takeover 
> to dom0. Moving ownership to dom0 doesn¡¯t mean a simple 
> move, since memory sub-system is the core/base of Xen

Very true.  But I expect Xen's memory subsystem will need
to evolve considerably to handle things like:

- support of different page sizes
- cacheable vs uncacheable memory
- sparsely populated memory
- hotplug memory
- oversubscription
- memory reserved for firmware

Now might be a very good time to consider alternative
approaches rather than try to hack these one at a time
into the existing memory subsystem of core/base Xen.

> Extra 
> context switches are added for any page related operation.

Hmmm... not really.  Page operations (such as alloc and free)
are relatively rare and can be batched (e.g. at domain startup).
And domU's are not going to be making policy decisions...
If dom0 is making policy decisions (e.g. this stick of RAM is
about to die, who do I steal memory from?), dom0 ownership
of the pages may even reduce context switches.

> Also by P==M model, how do you ensure a scalable allocation 
> environment after a long run? Any activities within dom0 
> which consumes Physical frames, thus actually eats Machine 
> frames.

Just like today's balloon driver, a "machine memory policy
driver" would steal all but some fixed number of dom0's pages
such that the dom0 kernel cannot use them for other purposes.


Xen-devel mailing list

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