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-ia64-devel

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

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: Re: 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: Thu, 12 Jan 2006 06:50:26 -0800
Cc: James Bulpin <james@xxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 12 Jan 2006 14:57:07 +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: AcYXh4XUbUr+PqleQQ2W4QRKnoZn2w==
Thread-topic: Re: Ownership of machine pages: Was: [Xen-devel] Essay on an important Xen decision (long)
(Sorry again for the late and off-thread reply... even though
your message is addressed to me personally, to xen-devel,
and to xen-ia64-devel, I didn't get a copy and just saw it
in xen-devel which I only receive digested.  Some strangeness
in the mailing list nodupe feature maybe?  James cc'ed....)

Yes, I think I could do a short presentation about what
I perceive are the issues and my (admittedly half-baked)
solution, but this would probably be better as a discussion
or brainstorming session than a "classroom" session
with 50 people listening.

> In a literal/extreme form of your model, any address space 
> access/update would need to be translated and/or validated by 
> domain0.

The literal/extreme form of just about *any* model generally
sucks ;-)  I'm thinking that Xen retains lookup tables so
all accesses are low cost, but (most) updates require domain0.
I think (without enough expertise in Xen/x86 memory management)
that the sticky overhead part will be page-flipping for netif:
Is there any "page affinity" for skbuffs or are they random pages?

Dan

> From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
> Subject: Re: Ownership of machine pages: Was: [Xen-devel] Essay on an
>       important Xen decision (long)
> 
> On 11 Jan 2006, at 22:49, Magenheimer, Dan (HP Labs Fort 
> Collins) wrote:
> 
> >> 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.
> 
> In a literal/extreme form of your model, any address space 
> access/update would need to be translated and/or validated by 
> domain0. 
> That's certainly going to be a significant overhead. I believe that 
> there is a balance to be struck between sufficient mechanism 
> in Xen to 
> ensure good performance while allowing flexible policy expression in 
> the control plane. I think talking about this at the summit would be 
> very interesting -- are your ideas solidified enough perhaps 
> even for a 
> short presentation?

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

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