Re: Ownership of machine pages: Was: [Xen-devel] Essay on an important Xen decision (long)

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

(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