> Date: 2006年1月11日 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
- NUMA
- 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.
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel